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interest in them has been high. And so, not 
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But now Visible Systems is offering state-of- 
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The Visible Analyst Workbench is the 
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The Visible Analyst features a custom 
symbol generator, multiple line styles and text 
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between diagrams and dictionary without even 
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or a robin shelf and select instead a veri¬ 
fied design for a martin apartment. 

For computer hardware, we also seek 
proof of correctness—verification that 
the notions match the specification- 
before committing to the application. In 
this issue, Paolo Camurati and Paolo 
Prinetto describe formal verification 
methods, where the proof is mathemati¬ 
cal rather than experimental. Their arti¬ 
cle, “Formal Verification of Hardware 
Correctness: Introduction and Survey of 
Current Research,” begins on page 8. 
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President’s MESSAGE 



Edward A. Parrish, Jr. 


O ne of our principal interests 
this year has been to enhance 
the Computer Society’s inter¬ 
national activities and membership. For 
this month’s column, I have asked 
Executive Director T. Michael Elliott to 
report on some of the recent develop¬ 
ments in this arena. 

Edward A. Parrish, Jr. 

President 


The transnational Computer Society 


Like the IEEE and its predecessor 
organizations, the Computer Society 
has been a transnational society from its 
very beginnings. We have long 
benefited from the participation of our 
members from all over the world. For 
example, such key conferences as the 
International Conference on Software 
Engineering, the Fault-Tolerant Com¬ 
puting Symposium, and the Interna¬ 
tional Conference on Distributed 
Computing Systems regularly convene 
outside the US and depend heavily on 
leadership from volunteers in the host 
countries. In 1986 we established a new 
conference series, CompEuro, which is 
held in a different country in Europe 
each year, and just last year Compsac, a 
traditionally US-based conference, was 
held for the first time in Tokyo. 

Our publications program has always 
reflected our international character, 
with articles, papers, and theme issues 
on important research, development, 
and applications in countries around 
the world. Also, many of the society’s 
technical committees regularly hold 
workshops outside the US, and our 
standards development efforts are being 
recognized as leading the industry 
worldwide. The list of examples is long, 
but the important point is that the soci¬ 
ety has a well-established tradition of 
both serving and using the expertise of 
its members all over the world. 

While our transnational tradition has 
long been recognized, new trends are 
emerging that make it more evident. 
Principal among these is that the annual 
rate of growth of non-US society mem¬ 
bers has begun to exceed the US mem¬ 
ber growth rate. As shown in the 
accompanying chart, approximately 
one-quarter of all the society’s members 
(all grades) are residents of IEEE 
Regions 7-10. The biggest international 
segments are Region 8 (Europe, Middle 
East, and Africa) and Region 10 (Asia 
and the Pacific Rim). 

Despite this international growth and 
activity, as a practical matter the soci¬ 
ety’s operations have largely centered in 
the US. But that, too, has begun to 


change. In 1984, Board of Governors 
Members Paul Borrill and Herb Weber 
urged establishment of a European 
office. At a planning meeting of the 
Executive Committee organized by 
President Martha Sloan in early 1985, 
the creation of such an office was estab¬ 
lished as a goal for implementation later 
that year. Beginning with a single staff 
person and very conservative plans, the 
office opened in Brussels in November 
1985 and has since proven to be an 
unqualified success. The office serves 
society members in the region by offer¬ 
ing information and assistance by 
phone, letter, or fax. New memberships 
and subscriptions are processed in a 
variety of European currencies and 
expedited. Currently, over 100 new 
members are joining through the Brus¬ 
sels office each month. Orders for pub¬ 
lications of the Computer Society Press 
are accepted in a variety of European 
currencies and given expedited han¬ 
dling, cutting weeks off the delivery 
time of overseas orders placed with our 
California distribution center. Overall, 
book sales have shown substantial 
growth, now generating sufficient reve¬ 
nue to cover the cost of the office and 
its service to members. A program that 
provides important services to society 
members without requiring a subsidy 
meets the truest test of success in an 
organization like ours. Much of the 
credit for that success must go to Euro¬ 
pean Activities Committee Chair Jac¬ 
ques Tiberghien and European 
Operations Manager Nell Nachtergal. 

Encouraged by our success in 
Europe, the Board of Governors 
initiated a feasibility and planning study 
for an Asian office in mid-1987. Presi¬ 
dent Roy Russo appointed a study com¬ 
mittee headed by Board Member 
Akihiko Yamada, and based on the 
committee’s report, the board last 
November approved the creation of an 
office in Tokyo. Those plans are now 
being implemented, and we hope the 
office will be operating next month. A 
manager of the new Asian Office, 

Kyoko Mikami, has been hired, and we 
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expect to have signed a lease for office 
space by the time this appears in print. 
Establishing an overseas office is a com¬ 
plicated process, but our experience in 
Europe has led to a better understand¬ 
ing of the problems, and things seem to 
be progressing smoothly in our Asian 
venture. 

The first international meeting of the 
Executive Committee was held last 
April during CompEuro in Brussels. 
While there, the committee visited the 
European Office of the Computer Soci¬ 
ety and hosted a reception for leaders of 
several leading computer professional 
societies in Europe. Contacts made are 
being followed up as part of President 
Ed Parrish’s priority goal of forging 
closer relationships between the Com¬ 
puter Society and the societies of com¬ 
puter professionals in other nations. 
Some will qualify for affiliate society 
status. With all, we seek to engage in 
cooperative ventures, such as confer¬ 
ence cosponsorship. Whether it’s 
Gesellschaft fur Informatik in Germany 
or the Information Processing Society 
of Japan, both our members and theirs 
can benefit from collaboration and 
sharing of programs. 

The Computer Society has long been 
the world’s largest society of computer 


professionals. Its scientific, literary, 
and educational purposes are worldwide 
in scope, and our technology itself 
makes a worldwide, transnational soci¬ 
ety a workable concept. It has become a 
cliche to talk about our shrinking 
world, but the cliche is based in fact. 
This report was composed on a laptop 
in a hotel room in Tokyo. From there it 
was transmitted to the society’s maga¬ 
zine editorial offices in California via 
the society’s electronic mail utility, 
Compmail + . After editing, it was elec¬ 
tronically transmitted to a typesetter, 
printed, and ultimately distributed all 
around the world. In the future, we can 
expect more exciting changes in the 
means of distribution, relying on the 
technology being developed and applied 
by our members. 

By emphasizing our international 
activities this year, President Parrish is 
in no way diminishing our activities and 
programs carried out within the United 
States. Rather, he is recognizing our 
worldwide membership and reinforcing 
the society’s role as the premier player 
on the world stage of the computing 
professions. 

T. Michael Elliott 

Executive director 




US (Reg. 1-6) 76% 


Asia, Pacific Rim 
(Reg. 10) 8% 

Latin America (Reg. 9) 2% 

Europe, Middle East, 
Africa (Reg. 8) 10% 


Canada (Reg. 7) 4% 


Non-US (Reg. 7-10) 24°/< 


Approximate distribution of Computer Society members, all grades. 
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•chiefs MESSAGE 


A very special ‘Thanks’ 


While at IBM’s Thomas J. Watson 
Research Center, I was blessed with a 
particularly capable, creative, and ener¬ 
getic administrative assistant, Faith 
Compo. I left IBM in mid-June to join 
the faculty of the University of Hawaii 
and am taking this opportunity to per¬ 
sonally thank her. She was a tremen¬ 
dous asset to me and to two Computer 
Society magazines. 

She worked with me for four years — 
first during my final two and a half years 
as editor-in-chief of IEEE Software and 
then during my initial year and a half as 
editor-in-chief of Computer. In her 
capacity as administrative assistant, she 
dealt with engineers, scientists, and 
managers from industry, government, 
and universities from both the United 
States and abroad both as authors and 
referees. Her interactions with these 


people were conducted in such a profes¬ 
sional manner that she at once gained 
both their trust and their respect. Many 
of you who are reading this editorial 
will recall receiving one or more of her 
brief, personal, handwritten notes of 
inquiry or thanks and will remember 
with pleasure the many excellent quali¬ 
ties she brought to the job. 

She had a very important role in 
making sure these two magazines were 
published in a timely manner. Although 
she is not a member of the Computer 
Society, she is one of its unsung heroines. 

Faith, thank you very much. I, as 
well as our authors and referees, will 
miss you dearly. 

Bruce D. Shriver 

Editor-in-chief 
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Use the application on page 
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Bruce D. Shriver, Computer's editor-in chief, left IBM in mid-June to join the Uni¬ 
versity of Hawaii. He was appointed the Henry A. Walker, Jr., Distinguished 
Professor of Business Enterprise and the director of the Pacific Research Institute 
for Information Systems and Management. PRIISM is focusing on information 
systems and technology in multinational, multicultural, multilingual settings, with 
particular emphasis on Pacific Rim nations. Shriver’s work on Computer will con¬ 
tinue, but it will be without the able assistance of Faith Compo, his administrative 
assistant at IBM, who contributed much to Computer. 
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tool, use one of these use Design/2.0™ 
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IBM PC-AT and PS/2 are registered trademarks of International Business Machines Corporation. 

Windows is a trademark of Microsoft Corporation. Macintosh is a trademark of 
Apple Computer, Inc. Design/2.0 is a trademark of Meta Software Corporation. 



A lot of tools can help you draw, but how many help you 
design and keep track of complex system models? 
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Design/2.0 does it faster and more efficiently than any other tool! 
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Once you connect two objects, they stay connected. Move or resize 
an object and its connections are automatically redrawn. 

Design/2.0 also redraws all associated objects and text. 

Use Design/2.0’s flow chart symbols or create or import your own. 
Create and edit text anywhere in your diagram. Even do word 
searches. Associate text with objects or connectors. Or create 
hypertext links across pages. 

The big picture is easy to see 
As your model evolves, move detail to subpages. Build diagrams 
containing hundreds of hierarchically linked pages. Design/2.0 
maintains all relationships and displays the hierarchy no matter 
how complex your model becomes. 

Why not spend your time designing, rather than drawing? 


Yes, I want to spend my time designing! Please send me more 
information on Design/2.0. 
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SURVEY & TUTORIAL SERIES 



Formal 
Verification 
of Hardware 
Correctness: 

Introduction and Survey 
of Current Research 

Paolo Camurati and Paolo Prinetto 


Politecnico di Torino 


T o verify is to prove the truth of 
something by presenting evidence 
for it.” To benefit from this 
dictionary-like, generic definition, we 
must tailor it to the particular domain we 
want to consider: the design of hardware. 

Every design, no matter how strategic or 
complex, requires multifaceted verifica¬ 
tion before marketing. Starting from final 
manufacturing and moving back through 
previous phases of the process, we might 
find many objects for verification. Low- 
level design rules, timing, high-level design 
rules, firmware, functional correctness, 
and base software might attract our 
interest. The domain of verification spans 
all phases of design, covering hardware, 
firmware, and software. We restrict our 
discussion in this article to one particular 
item—the verification of functional cor¬ 
rectness through formal techniques. 

Let us begin by giving two definitions of 
functional correctness, which we will use 
throughout. First, at every design step, the 
designer specifies what the system under 
development should do and how it should 
do it. What the system should do is called 
its specification, while any one of the pos¬ 
sible devices that realizes the specification 
is called an implementation. The design of 
a system may reduce to an iteration of 



To formally verify 
hardware correctness, 
we need suitable 
representation 
systems and 
automated proofs. 
Logic, techniques 
from software 
verification, and 
automated synthesis 
benefit the process. 


specification/implementation steps, per¬ 
formed either top-down or bottom-up, 
where the implementation at level i 
becomes the specification for level / + 1. 
Any piece of hardware is functionally cor¬ 


rect if we can somehow prove that its 
implementation realizes the specification 
(see Figure 1). 

Other concepts of correctness exist. 
Sometimes it is useful to consider an exist¬ 
ing design and to verify some of its proper¬ 
ties. We can group such properties into 
two main classes: 

• safety properties and 

• liveness properties. 

Safety properties express conditions of 
the form “bad things will never occur.” 
Within the framework of branching time 
temporal logic (with multiple evolutions in 
the future, each consisting of a “path” 
connecting some ‘ ‘states’ ’ and expressing 
before/after relations between the events), 
an example of a safety property looks as 
follows: 

“for every path in the future, at every 
node on the path, if the Request sig¬ 
nal is low, it must remain low until 
Acknowledge goes low” 

Liveness properties express conditions 
of the form “good things will occur in the 
future. ” A branching time temporal logic 
example looks as follows: 

“for every path in the future, if there 
has been a Request signal, then even¬ 
tually there will be an Acknowledge 
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signal in response to the request on at 

least one node on the path” 

Safety and liveness properties play the 
role of partial specifications; that is, they 
do not describe device behavior globally, 
rather they cover limited aspects. We call 
a design correct with respect to the proper¬ 
ties if we can demonstrate that the proper¬ 
ties are true. This is our second definition. 
Since specifications are partial, we must 
take particular care in their selection, try¬ 
ing to cover all or as many good and bad 
things as possible. 

Obviously, correctness is not an autono¬ 
mous concept, but rather a relation 
between two entities: a specification and 
an implementation, or a property and a 
design. Verification to first principles is 
thus impossible—a verified design is only 
as good as its specification. Specification 
languages fail in being so involved and 
detailed that no practitioner would ever 
use them. Moreover, the specifications are 
as likely to have errors as the implementa¬ 
tion, and it is unlikely that anyone would 
ever first write a formal specification and 
then implement it. 

A possible classification of the relations 
between a specification a and an imple¬ 
mentation f) or a property a and a design 
P that must be demonstrated in a proof 
follows: 

• equality: a = p, 

• equivalence: a** p, 

• logical implication: a — p, 

• homomorphism: M (<t>(a)) = M(b) 
The last item, used in model-based 
approaches in first-order predicate calcu¬ 
lus, consists of defining a function (the 
homomorphic function <(>) and a mapping 
M that makes possible the comparison 
between a model of the specification and 
a model of the implementation. Specifica¬ 
tions and implementations often fall at 
different levels of abstraction, thus we 
must transform them through a $ func¬ 
tion: structural abstraction consists of hid¬ 
ing internal lines, data abstraction 
transforms a data type into another data 
type, and temporal abstraction takes into 
account timing models and time’s 
granularity. 

In this article we analyze formal verifi¬ 
cation techniques focusing on two key 
points: suitable representation systems and 
mechanizable proofs. But before we look 
at current research efforts, we will briefly 
discuss related topics to make them under¬ 
standable to novice readers. 

First we report on different approaches 
to hardware verification. We compare for- 
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Figure 1. Correctness. 


mal verification and automated synthesis 
to show how they cooperate in producing 
zero-defect designs. Next we present the 
necessities for formal verification tech¬ 
niques: formal representation systems and 
the related reasoning facilities. For each 
technique we consider some of the main 
efforts related to it and evaluate them. A 
reading list covers the specific topics for 
those interested in exploring further. The 
reading list includes all works on which we 
based our discussions. Finally, we evalu¬ 
ate the different approaches and show the 
promise of research in this field. 

Approaches to 
hardware verification 

We can verify the correctness of hard¬ 
ware in many different ways, such as 
through breadboarding, simulation, and 
formal proof. 

Rising design and fabrication costs, 
market demands, circuits moving toward 
very-large-scale integration, and growing 
system complexity made the use of a pro¬ 
totype for extensive testing almost impos¬ 
sible. Breadboarding has also dwindled 
because parasitics, thermal and electrical 
characteristics, and component-matching 
properties differ for discrete components 
and VLSI. Nowadays, breadboarding for 
VLSI is restricted to very special applica¬ 
tions, such as systems used in space flights. 
Breadboarding’s limits forced the exten¬ 
sive use of simulation in establishing hard¬ 
ware correctness. 

Simulation differs from breadboarding 


mainly in the presence of a model of the 
system under consideration. Although 
there are various notations to describe the 
models, the ultimate goal of using them is 
to allow the operation of a simulation 
engine. 

Simulation-based design evaluation 
steps through the following phases: 

(1) Model description in a suitable 
language 

(2) Test input stimuli generation 

(3) Simulation 

(4) Result extraction from simulation 

(5) Extracted and expected data com¬ 
parison 

(6) Circuit/system redesign 

The last three phases have been success¬ 
fully applied in commercially available 
systems. A major drawback of Step 3 as a 
means of establishing correctness or com¬ 
puting performances lies in the generation 
of input stimuli. If we must prove correct¬ 
ness with certainty and/or evaluate perfor¬ 
mance with accuracy, we should consider 
all possible input combinations and their 
sequences. This leads to an explosion of 
cases, which soon makes the approach 
unfeasible. 

Thus Step 2 replaces exhaustive simula¬ 
tion. The designer prepares a set of test 
cases that he or she considers sufficient to 
establish correctness. If extracted and 
expected data differ, something has gone 
wrong; otherwise, nothing can be stated 
unequivocally. As E.W. Dijkstra has 
remarked, “Non-exhaustive testing can be 
used to show the presence of bugs, but 
never to show their absence. ” The degree 
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Specification: 
two-bit: box; 

input start; 
output register c(0:l); 

| c = 0 A start | c = 1; 

| 0 < c < 4 | c = c+1; 

end box; 

(a) 


Implementation: 
two-bit: box; 

input start; 
output cO, cl; 
cO = JKFF(tt,cs,tt); 
cl = JKFF (tt,clock,ts); 
ts = OR2(tt,start); 
tt = OR2(cO,cl); 
cs = OR2(cl,ct); 
ct = AND2(clock,nt); 
nt = NOTl(tt); 
end box; 


(b) 


Figure 2. A two-bit counter with a behavioral specification under the form of a 
state transition description (a) and a structural implementation under the form of a 
network diagram description (b). 


Case 

C = 0ASTART=1 
C = 0aSTART = 0 
C<>0 


Case 

C0 = 0AC1=0ASTART=1 
C0 = 0 A Cl =0 A START = 0 
C0=1 VC1 = 1 


Specification result 
C = 1 
C = 0 
C = C+1 


Implementation result 
C0 = 1 C1=0 
C0 = 0C1=0 
C0 = C1 xorCO 
Cl = ~C1 A CO 


Figure 3. Given beginning specification and implementation values, we can find 
and manipulate symbolic values to establish equivalance. 


of confidence the designer has in the simu¬ 
lated system depends on the quality of the 
test cases. 

Another crucial point, common to 
simulation and formal verification, is Step 
1. The model must, in fact, represent the 
real system accurately, otherwise it is not 
only useless, but misleading, too. 

Having established the limits of simula¬ 
tion, we could continue with an enhanced 
simulation-based approach to verification; 
abandon simulation, resorting to formal 
methods to prove hardware correctness; or 


integrate various approaches, both formal 
and simulation-based. 

As far as the first choice is concerned, 
we could resort to symbolic simulation, an 
offspring of conventional simulation 
because it uses a model for hardware and 
a simulation engine, but differing from it 
in considering symbols rather than actual 
values for the circuit under consideration. 
In this way we can simulate the response 
to entire classes of values with a notable 
improvement over traditional techniques. 

Symbolic simulation extends to verifica¬ 


tion of correctness because specifications 
and implementations can be run concur¬ 
rently and the results manipulated and 
compared to establish a proof. As an 
example, let us consider a two-bit 
counter 1 with a behavioral specification 
under the form of a state transition 
description and a structural implementa¬ 
tion under the form of a network diagram 
description (see Figure 2). Note that the 
descriptions resort to different timing 
models and that there is no explicit conver¬ 
sion function from natural numbers to bit- 
vectors. The correspondence between 
states and output values of the two 
machines is given by a simulation relation 
that must hold at each clock tick: 

Specification Implementation 

start = start 
c(0) = cO 
c(l) = cl 

Starting specification and implementation 
with c = C and start = START, we find and 
manipulate symbolic values to establish 
equivalence as shown in Figure 3. Trivial 
equivalence cases are easily solved. We 
leave nontrivial ones, such as proving that 
some bit-vector operations realize integer 
addition, to theorem provers. 

A novel and promising approach to 
hardware verification is formal verifica¬ 
tion. The key concept lies in the word “for¬ 
mal”: it means that the proof is 
mathematical, rather than experimental. 
Mathematical demonstration overcomes 
the limits of test-case simulation, since it 
is valid for all input stimuli under specified 
assumptions. 

Formal verification needs suitable sys¬ 
tems to represent the objects it considers 
(specifications, implementations, proper¬ 
ties) and means to perform proofs. Formal 
systems must be mathematically sound 
and tailored to the domain of application, 
that is, to the classes of designs to be 
verified. 

Hybrid approaches use formal tech¬ 
niques and exhaustive simulation, such as 
enumeration on a restricted set of vari¬ 
ables, trying to balance proof power and 
computational efficiency. 

We can also use formal techniques to 
transform a design. In this case we talk of 
“correctness-preserving transforma¬ 
tions.” Such techniques are particularly 
useful when integrating verification and 
automated synthesis in a cooperative 
approach to correct hardware design. A 
correctness-preserving transformation 
takes a correct implementation of a spec- 
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ification and derives another correct 
implementation. We use these transforma¬ 
tions to generate design alternatives to 
improve the quality of some original solu¬ 
tion, to explore the design space, and to 
prove the equivalence of two hardware 
descriptions. 

Formal verification versus automated 
synthesis. The goals of automated synthe¬ 
sis and of verification seem mutually 
exclusive: the former aims at correct-by¬ 
construction designs, while the latter tar¬ 
gets the proof of post-factum designs. For¬ 
mal verification does not consider aspects 
such as area, cost, and performance. We 
can regard formal verification as an ancil¬ 
lary approach, replaceable by synthesis as 
soon as synthesized designs surpass hand¬ 
made ones. 

Given the restricted domain of formal 
verification, we can reasonably suppose 
that it will reach its goals sooner than syn¬ 
thesis, although a circuit 90-percent syn¬ 
thesized is more useful than a circuit 
90-percent verified—the subtle bugs will 
occupy the unverified 10 percent. More¬ 
over, formal verification helps in defining 
the concept of correctness and correct-by¬ 
construction design methodologies. Thus, 
both approaches benefit from the 
advancement of the same theoretical 
studies. 


Formal systems for 
hardware representation 

Since the difference between formal and 
simulation-based verification lies in the 
presence of a mathematical proof, it is 
essential to have a formalism to represent 
hardware systems at all levels of abstrac¬ 
tion. Such a formalism requires a com¬ 
plete, precise, and coherent definition of 
the underlying semantics. Consequently, 
we associate with each formal system a set 
of calculation properties allowing mathe¬ 
matical proofs. 

We can distinguish semantics as opera¬ 
tional, denotational, or axiomatic. 2 

Operational semantics defines the 
meaning of any term of a formalism in 
terms of the actions performed by an 
abstract state machine that interprets the 
statements written in the formalism. 

Denotational semantics entails an 
abstraction of the interpretation mecha¬ 
nism, since it introduces a model that views 
a term as a function transforming states 
into other states. Denotational semantics 


Figure 4. A synchronous circuit. 


assigns meaning in terms of set and func¬ 
tion theories. 

Axiomatic semantics in the theory of 
programming languages means that some 
formulas of predicate calculus are 
associated with a program. From a mathe¬ 
matical point of view, this is just a trans¬ 
formation of a formal language not part 
of a formal system into a formal language 
for which a syntactical concept of deriva- 
bility exists. 

The next section presents logic, the most 
widely known and used formal system. 
Subsequently, we will present the use of 
programming languages for hardware rep¬ 
resentation, although they aren’t formal 
systems. Programming languages are 
widely used in conjunction with logic in 
software verification, and some authors 
extend their use to hardware, too, cross- 
fertilizing some ideas with software verifi¬ 
cation techniques. 

Formal logic 

Logic is that branch of knowledge con¬ 
cerned with truth and inference. It inves¬ 
tigates the structure of propositions and 
deductions, resorting to a method that 
abstracts from the contents of the propo¬ 
sitions in question and is related only to 
their form. A proposition is a declarative 
statement to which we can attach a true or 
false value. The meaning of a proposition 
is given by an interpretation in some 
“world,” while syntax is the only key 
available for us to manipulate and reason 
about. Ad hoc formalisms enhance the dis¬ 
tinction between form and meaning. Logi¬ 
cians have proposed various formalisms. 


We will briefly outline the most relevant 
ones in the domain we consider: 

• First-order predicates 

• Higher-order predicates 

• Specific calculi 

• Temporal logic 

First-order predicates. First-order 
predicates deal with propositions and 
propositional functions, that is, those 
functions where the domain of the 
independent variable ranges over propo¬ 
sitions. All usual logical connectives are 
defined as well as the existential (3) and 
universal (V) quantifiers. Interpretations 
of first-order predicates require a specified 
domain and symbols referring to entities 
within this domain. Different domains 
lead to different interpretations. 

The language of first-order predicates 
consists of terms, atoms, and formulas. 
The traditional approach outlined above 
is purely logical and does not provide the 
common concept of function. Thus, it is 
mainly used by Prolog-oriented 
researchers. Other authors prefer to intro¬ 
duce truth values in their formal systems 
rather than assigning them by means of an 
interpretation. Hence, they do not deal 
with predicates, rather they use functions 
with truth values as the range. 

Model theory offers another approach 
to first-order predicates. 3 Model theory 
deals with the relationship between a for¬ 
mal system and an algebraic structure that 
gives a meaning to it. 

Example. Consider the simple syn¬ 
chronous circuit 4 of Figure 4, consisting 
of a D-type flip-flop with clock input gated 
by a NAND gate. The goal is to show how 
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Figure 5. DDL verifier. 


first-order predicate calculus can describe 
structure and behavior. The device resorts 
to a precise-delay timing model. 

The description in terms of first-order 
predicates expresses behavior as a set of 
time functions, possibly with initial or 
generic conditions. It looks as follows: 

ck(t) = nand(a(t - d„ and ), 

clock(t-d„ and )), 

//(0) = L, 

=0) A (re(ck(t) = L)) => 

m) =//(?-!)), 

=0) A (re(ck(t) = H)) => 

m) = y(t)), 

x(t) =mt-d ff ) 

Function re detects the rising edge of a sig¬ 
nal, d„ and is the delay of the NAND gate, 
and d /f is a propagation time through the 
flip-flop. 

Research. T.J. Wagner of Stanford 
University, California, first attempted to 
apply predicate calculus to the verification 
of hardware using an available theorem- 
prover for a number of simple proofs of 
unit-delay descriptions. 

A.S. Wojcik of Illinois Institute of 
Technology, Chicago, presented Aura, the 
Argonne Automated Reasoning Assistant, 
an experimental system for formal verifi¬ 


cation. The axiom set includes rules for 
Boolean algebra, signal specifications, and 
structure handling. Wojcik described spec¬ 
ifications and implementations at the 
register-transfer level using a clause form. 

J.C. Barros of Shell Development, 
Houston, Texas, and B.W. Johnson of the 
University of Texas, Dallas, used first- 
order predicates to describe some classes 
of commonly used synchronous circuits, 
such as arbiters, synchronizers, latches, 
and inertial delays. They defined axioms 
in a ternary algebra which, in addition to 
the standard values true and false, has the 
unknown value u. They introduced two 
kinds of axioms, constraining the outputs 
or allowing partial inference of output 
behavior from input behavior. The predi¬ 
cates included parameters to specify tim¬ 
ing conditions. Theorem proving 
demonstrated correctness, but no 
mechanization of this approach has been 
reported. 

N. Suzuki of the University of Tokyo 
explored a hybrid methodology between 
simulation and formal verification. The 
specifications, represented by input/out¬ 
put assertions in first-order predicates, tie 
the method to formal verification. Instead 
of showing that the implementation for all 
inputs satisfying input assertions satisfies 
output assertions, Suzuki showed that this 


holds only for selected inputs, called test 
data. The main interest of this approach 
lies in the language the author used for 
description: Concurrent Prolog, a logic¬ 
programming language that allows con¬ 
currency and efficient backtracking by 
means of guards and commit operators. 
Suzuki’s approach was applied to the 
memory of Dorado, a high-performance 
personal computer designed at Xerox Palo 
Alto Research Center. 

T. Uehara, T. Saito, F. Maruyama, and 
N. Kawato of Fujitsu Laboratories, 
Kawasaki, Japan presented a system called 
the DDL Verifier (see Figure 5), applied to 
synchronous systems at the functional 
level. Implementations are described in the 
DDL language and specifications are first- 
order predicates. A translator reduces the 
circuit under consideration to cause/effect 
tables, which show necessary and suffi¬ 
cient conditions for circuit operations. The 
proof method uses backward reasoning 
and proof by contradiction. First, the 
specification is negated and then traced 
backward using cause/effect tables to 
show that it is always false. The DDL Veri¬ 
fier takes time into account, exploring 
truth and falsity in present and past states 
of the circuit under consideration. In a 
later paper, the authors abandoned first- 
order predicates as a means of expressing 
specifications and resorted to temporal 
logic. 

H. Eveking of the Technische Hoch- 
schule Darmstadt, Federal Republic of 
Germany, introduced a fundamental dis¬ 
tinction between vertical and horizontal 
verification. Vertical verification means 
compliance between the specification and 
the implementation of a circuit. When the 
behavior of a device is described, a model 
is created and associated with the real 
object. Such a model is valid only if the 
environment in which it operates satisfies 
a set of constraints; thus, the device 
behaves as specified in the description. 
These constraints, called assertions, may 
refer to any point in the device. When 
devices interconnect in a more complex 
structure, you must extract a set of inter¬ 
face assertions that have no ties to internal 
points and that guarantee—if satisfied— 
that internal assertions also hold. Eveking 
calls this process of composing assertions 
and propagating them outwards horizon¬ 
tal verification. A support tool for such a 
methodology is Vertico, an expert system 
for generating interface assertions through 
predicate transformation. 

For vertical verification, Eveking con¬ 
sidered synchronous systems described in 
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SMAX, a nonprocedural hardware 
description language belonging to the 
Conlan family. Eveking considers HDLs 
formal languages but not formal systems. 
Thus, HDL descriptions must be axioma- 
tized and transformed into first-order 
predicates. The predicates associated with 
a description may be classified as logical 
axioms, that is, general-purpose axioms; 
HDL-specific axioms; and description- 
specific axioms. The formal system pro¬ 
vides a set of inference rules; axioms and 
inference rules form a theory. This set of 
entities allows a precise definition of cor¬ 
rectness: an implementation is correct with 
respect to a specification if the nonlogical 
axioms of the former are theorems in the 
latter’s theory. When specification and 
implementation occupy different abstrac¬ 
tion levels and/or use different timing 
models, you must introduce an interpreta¬ 
tion of a language (or a theory) in another 
language (or theory), thus generating a 
suitable mapping. 

Mechanization of this approach is under 
study, but for efficiency’s sake, instead of 
a general-purpose theorem-prover, Evek¬ 
ing uses a set of smaller and specialized 
provers whose activation is controlled by 
an expert system integrating frames and 
production rules. 

W.A. Hunt of the Institute for Comput¬ 
ing Science and Computer Applications at 
the University of Texas, Austin, used 
Boyers-Moore logic to describe and verify 
theFM8501 microprocessor. The specifi¬ 
cation is the microprocessor viewed as an 
instruction interpreter; that is, for every 
possible instruction, a new microprocessor 
state is defined. The implementation is a 
graph of logic gates. The formalism con¬ 
sists of quantifier-free first-order predi¬ 
cates. Recursive functions provide the 
primary means of description for hard¬ 
ware devices. Time is only implicitly 
modeled as a stream of values, which con¬ 
stitutes a weakness of this approach. The 
objects the author considered are bit- 
vectors of arbitrary size, natural numbers, 
and integer numbers. Specifications and 
implementations are both expressed as 
recursive functions. Implementations, or 
hardware formulas, can be automatically 
expanded to yield structural descriptions. 

Evaluation. First-order predicates rep¬ 
resent a substantial share of current 
research efforts. They are important both 
from methodological and practical points 
of view. In particular, studies with first- 
order predicates have contributed to the 
understanding of their expressive limits 


and fostered research on higher-order 
predicates. 

Higher-order predicates. Higher-order 
predicates represent an enhancement of 
first-order predicates. They extend the 
notation of first-order predicates in that 
the domain of variables also ranges over 
functions and predicates, and functions 
can take functions as arguments and 
return functions as results. As an example, 
consider how we could express a falling 
clock signal: 

Vclock t. (Fall clock) t = clock(t) A 
~clock (t + 1) 

The variable clock has time functions as 
domain—that is, functions from time— 
modeled as positive integers, to Boolean 
values. Fall is a higher-order function 
accepting clock as an argument and 
returning a predicate on positive integers. 

Unrestricted higher-order predicates 
suffer from a number of paradoxes, 
avoided by resorting to type theory and 
type hierarchy. Higher-order predicates 
generally contain the axioms of infinity 
and choice. The infinity axiom states that 
the domain of individuals is infinite; the 
choice axiom allows us to introduce new 
primitive formulas. 

Example. This example illustrates the 
use of higher-order predicates to represent 
parameterized systems such as an w-bit 
adder. 5 An «-bit adder computes an n-bit 
sum and one-bit carry-out from two n -bit 
inputs and a one-bit carry-in. The lines c in 
and c ou , carry one-bit words and the lines 
a, b, and sum carry n-bit words. One-bit 
words are modeled as Booleans; /z -bit 
words are modeled as functions mapping 
natural numbers into Booleans. The spec¬ 
ification follows: 

Adder (n)(a,b,c in ,sum,c out) = 

( 2 « + i * Bit-Val(c out ) + Val(n,sum) = 
Val(n,a) + Val(n,b) + Bit-Val (c in )) 

The higher-order function Adder applied 
to the «-bit number yields a predicate 
specifying the corresponding adder. The 
function Bit-Val relates the logical values 
true and false with numbers 1 and 0; Val 
transforms bit-vectors recursively into 
numbers. 

You can implement an n- bit adder by 
connecting n full adders. The inputs are a 
single bit-carry in c,„ and two n -bit words, 
a n _ i . . . a 0 , b„ _1 . . . b 0 . The outputs 
are an n -bit sum, sum„ _ , . . . sum 0 , and 


a one-bit carry-out, c ou ,. The implementa¬ 
tion uses a recursively defined higher-order 
function, Add-Imp, which when applied 
to a number n yields the predicate specify¬ 
ing the implementation of an n-bit adder. 
The recursive part of the function says that 
you build an n -bit adder by first building 
an n - 1-bit adder and then connecting its 
carry-out to the carry-in of a one-bit 
adder: 

Add-Imp (n)(a,b,c in ,sum,c oul ) = 

3 c.Add-Imp (n )(a,b,c in ,sum,c) A 

Add\(a (n), b (n ), c.sum (n ),c out ) 

Research. F.K. Hanna and N. Daeche 
of the University of Kent, United King¬ 
dom, presented a system called Veritas for 
specification and verification of hardware. 
Specifications, written in higher-order 
logic, are partial and hierarchical, and they 
can take into account low-level timing 
issues. A designer’s knowledge of digital 
systems is structured as a set of theories, 
each defined by a theory presentation con¬ 
sisting of a set of symbol declarations and 
a set of axioms. Theorems can be deduced 
from axioms using inference rules. The 
Veritas system is supported by various 
software tools for establishing and han¬ 
dling the theory database using a func¬ 
tional programming language, ad hoc 
parsers, user-defined inference rules, and 
goal-directed theorem-pro vers. The 
Veritas approach is interesting from a 
methodological rather than from a prac¬ 
tical point of view, examples being limited 
to very simple gates. 

M.J.C. Gordon of the University of 
Cambridge, United Kingdom, is another 
British author who migrated to higher- 
order lo^ic. We describe his earlier work 
in the section “Specific calculi.” His for¬ 
mal system based on higher-order predi¬ 
cates is called HOL, but the same name is 
given to the automatic theorem-prover. 
HOL as a formal system is polymorphic (it 
allows types containing type variables) and 
has Hilbert’s operator to build the choice 
axiom. 

To avoid paradoxes, Gordon imposed 
some restrictions on terms (they must be 
“well-typed”) and introduced some vari¬ 
ations in terminology: 

• A sequent is a set of assumptions from 
which a conclusion follows. 

• A theorem either is an axiom or fol¬ 
lows from other theorems by means of 
inference rules. 

• A theory is a set of types, type opera¬ 
tors, constants, definitions, axioms, and 
theorems. 
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In pure logic, a theory contains all possi¬ 
ble theorems, whereas in HOL it contains 
only axioms and already proved theorems. 
Gordon gave two theories as primitive: 
Booleans and Individuals, introducing for 
the latter the axiom of Infinity to generate 
infinite sequences. 

M. J.C. Gordon, J. Joyce, and G. Birt¬ 
wistle of the University of Calgary, 
Canada, with the HOL system verified a 
microprocessor originally specified and 
verified with LCF-LSM (logic of computa¬ 
ble functions/logic of sequential 
machines). D. May and D. Shepherd of 
Inmos, Bristol, United Kingdom, are using 
HOL to derive correct microcode for the 
IMS T800 floating-point transputer. 

Evaluation. Higher-order predicates 
have more expressive power than first- 
order predicates, but the trade-off for this 
advantage involves more difficulty in per¬ 
forming proofs and mechanizing. The 
integration of higher-order predicates with 
functional approaches looks like a trend 
for future development. 

Specific calculi. Many authors, espe¬ 
cially in the domain of hardware verifica¬ 
tion, create their own formal systems 
reducible to first-order or higher-order 
predicates. We will call these formalisms 
“specific calculi. ” Such calculi are defined 
along the lines of logic by giving legal con¬ 
nectives, terms, and rules for constructing 
formulas and performing inferences. 

Example. Consider the case of a unit- 
delay directional wire, 6 shown in Figure 
6. This device operates synchronously 
within a discrete model for time according 
to the state-transition graph shown in the 
figure. 

The device is defined by two input ports 
(a and t), an output port (fi), and two states 
(W and W') through which the circuit 
evolves at every clock tick according to the 
events on the input port a. Input to a may 
only occur when the timer ticks, so an a 
signal only occurs with a t signal. The sig¬ 
nal will propagate through the wire and is 
output on the next t signal, either on its 
own or simultaneously with a further input 
on a. The timer may tick without any input 
appearing, since it models the passage of 
real time (which cannot be halted). 

W~-tW + (at)W' 

tV'~-(pt)JV + (apt) W’ 

Research. G. J. Milne of the University 
of Edinburgh, United Kingdom, presented 


Circal, a calculus to describe and analyze 
circuit behavior. Circal is based on dot cal¬ 
culus, a descriptive language consisting of 
construction operators together with 
objects representing primitive concepts. 
Objects are composed to yield descriptions 
and communicate through labeled ports, 
called “sorts.” Circal describes the 
behavior of a computing agent by the 
actions it wishes to perform with other 
agents in the environment. Circal descrip¬ 
tions are based on the notion of event, that 
is, a trigger that starts a particular evolu¬ 
tion through time, resulting in a state. 

When composing more devices, you 
often must reduce their complexity to keep 
them manageable. You can do this by hid¬ 
ing internal ports, making them invisible 
to an external observer. 

The use of Circal is not restricted to a 
specific domain: it is both a very special 
hardware-description language and a 
framework for device analysis, in partic¬ 
ular for formal verification of partial or 
total specifications and for “constructive” 
simulation. The last concept represents a 
variation with respect to standard simula¬ 
tion: instead of simulating a whole device 
composed of many elements, Milne simu¬ 
lated the elements one by one and com¬ 
posed the results. A proof demonstrated 
the equivalence of the standard and con¬ 
structive approaches. 

Circal does not just verify single designs, 
but also demonstrates the correctness of 
classes of designs generated by the same 
simple silicon compiler using NOR expres¬ 
sions as specifications. Circal tools in a 
Lisp-based environment and related pro¬ 
totype systems support expression manip¬ 
ulation and Circal simulation, but not 
correctness proofs as such. 

An interesting library of LSI and VLSI 
components has been created and is 
reported in Circal. 

M.J.C. Gordon produced the LCF- 
LSM system. LCF, or logic of computa¬ 
ble functions, is a verification-oriented 
programming environment extensible to 
the manipulation of specifications. LSM, 
or logic of sequential machines, is a spec¬ 
ification language for synchronous sys¬ 
tems, currently used at the register-transfer 
and gate levels. The interface between user 
and LCF is provided by ML, an inter¬ 
preted metalanguage with side effects simi¬ 
lar to Lisp’s. LSM is tied to OL, a 
predicative object language assuming 
some concepts from the CCS, or calculus 
of communicating systems, proposed by 
Milner. 

LSM interfaces to LCF through four 


types: terms, constants, formulas, and the¬ 
orems. In OL, theorems are derived from 
axioms through rules of inference. Rules 
allow folding and unfolding, renaming, 
combining, pruning, and unwinding equa¬ 
tions. Axioms are grouped in theories, and 
theories in taxonomies. For the verifica¬ 
tion process, the user creates separate the¬ 
ories for specifications and implementa¬ 
tions, and generates a proof interactively 
by directing the system to use rules. Gor¬ 
don reported some examples of the appli¬ 
cation of his methodology to a simple 
computer and to an emitter-coupled-logic 
chip used in the Cambridge Fast Ring 
hardware. 

Gordon’s early work presented a for¬ 
malism to describe synchronous circuits 
based on recursive functions and lambda 
calculus. Specifications are given 
behaviorally, while implementations are 
structural connections of modules with 
assumed primitive behavior. Elementary 
behaviors are composed using catenation, 
connection, and hiding operators. Syntac¬ 
tic identity of expressions demonstrates 
equivalence of implementation and spec¬ 
ification. 

Gordon introduced the concepts of 
microcycles and macrocycles to represent 
systems that do not work in lockstep, that 
is, systems where a single operation at a 
higher level is implemented by a sequence 
of operations at a lower one. He also intro¬ 
duced the induction principle to take into 
account complex cases. The paper 
reported some examples of application to 
register-transfer systems and NMOS cir¬ 
cuits. Gordon’s early work inspired H.G. 
Barrow, D. Weise, and J.L. Paillet. 

H.G. Barrow of the Fairchild Labora¬ 
tory for Artificial Intelligence Research, 
Palo Alto, California, presented a verifi¬ 
cation system written in Prolog, called 
Verify, which stemmed from Gordon’s 
early work. Verify can check the correct¬ 
ness of finite-state machines. Behavioral 
specifications and structural implementa¬ 
tions are both described in Prolog. The 
system extracts from the structure the de¬ 
rived behavior and compares it with the 
intended one. To prove the identity of 
specification and implementation, Verify 
uses symbolic manipulations, such as sim¬ 
plification, expansion, and canonicaliza- 
tion. When they become too heavy 
computationally, it resorts to evaluation or 
enumeration, and thus to exhaustive simu¬ 
lation on selected variables. The interac¬ 
tive system has been applied to verify the 
same simple computer presented by Gor¬ 
don, and D74, a module for computing 
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sums of products. 

D. Weise of the Massachusetts Institute 
of Technology, Boston, Massachusetts, 
presented a methodology and a tool, called 
Silica Pithecus, to prove functional cor¬ 
rectness for designs at the switch level. 
Although it refers to NMOS, this 
approach is almost technology- 
independent. An ad hoc language 
describes specifications, while implemen¬ 
tations are described as schematics. The 
system extracts signals from the 
schematics, possibly still analog, and 
abstracts from these signals their digital 
behavior. Specified and intended behavior 
are compared to prove syntactic equiva¬ 
lence through symbolic manipulation and 
rewrite rules. 

J.L. Paillet of the Universite de 
Provence, Marseille, resorted to operative 
expressions to describe specifications and 
implementations. He then extracted the 
function of an implementation by com¬ 
posing the functions of the submodules 
and eliminating the internal variables. 
Eventually he compared, specified, and 
extracted behaviors to demonstrate 
equivalence. Internal variables are elimi¬ 
nated either by substitution or by a “devel¬ 
opment” operation (when looped). 
Concerning time, Paillet defined a “past” 
functional to allow references to past 
values of carriers. This approach focuses 
on synchronous circuits described at the 
register-transfer level. Mechanization is 
under way. 

Evaluation. Specific calculi are stand¬ 
alone formal systems especially tailored 
for hardware verification. From a theoret¬ 
ical point of view, they resemble first- or 
higher-order predicates. Some authors 
abandoned them, since they considered the 
trade-off between ad hoc formalisms and 
costs unfavorable. 

Temporal logic. In the domain of hard¬ 
ware representation, we must cope with a 
particular aspect of reality: time and tem¬ 
poral evolutions. Traditional logic is very 
powerful when dealing with static situa¬ 
tions, but it fails when dealing with 
dynamic ones. To satisfy hardware’s 
requirements, two choices seem possible: 

(1) an explicit introduction of the time 
variable t into predicate logic, or 

(2) a generalization of predicate logic to 
encompass the temporal domain. 

Following the first path, authors intro¬ 
duce time functions, treating time just as 
any variable, with the usual rules for 
terms, formulas, and inference. Following 


the second path, authors augment stan¬ 
dard logic to cover temporal evolution. 

First-order and higher-order predicates 
stand for eternal truths. Modal logic , on 
the other hand, introduces the concepts of 
possibility and necessity in the future. 
Modal logic, although more expressive 
than traditional predicate logic, still lacks 
the ability to cope with changes, an essen¬ 
tial feature in hardware behavior. To han¬ 
dle changes, we need a formal system that 
can reason from past events to what can or 
must be true at present and in the future. 
Such formal systems are generally grouped 
under the label “temporal logic.” 

Temporal logic includes all usual con¬ 
nectives and adds some typical operators. 
Although there are many variants, the 
basic operators are 

• henceforth □ 

• eventually o 

• next O 

• until U 

We can classify temporal logic systems 
according to the way they consider time. 
The framework being generally a discrete 
model for time, there are different ways of 
considering the future. The past is always 
linear, while the future may be either a 
unique world or a set of possible worlds. 
In the first case, time is linear in the future, 
too; such logic is called “linear temporal 
logic. ’ ’ In the latter case, time branches in 
the future; such a system is called “branch¬ 
ing temporal logic. ’ ’ In the former case, a 
system supposedly has a unique evolution 
along time, whereas in the latter case, a 
system has a set of possible evolutions. 

Linear and branching time are not the 
only distinctions in temporal logic. 
Another important one is instant-based 


versus interval-based logic. Temporal logic 
is instant-based when propositions are 
asserted on single states (that is, instants 
in discrete time) only. Temporal logic is 
interval-based when propositions are 
asserted on sequences of states (that is, on 
intervals in discrete time). “Interval tem¬ 
poral logic” may be either global or local. 
It is global when the truth of propositions 
is determined over an entire interval, that 
is, on all its states. It is local when truth is 
determined on the first state of an interval 
and holds unchanged on the rest. 

Linear temporal logic example. Con¬ 
sider part of the handshaking protocol 7 in 
Figure 7. Explanations appear between 
quotes. 

□ (~ Hear -*■ o Call) 

“if Hear is low, then sooner or later 

Call will rise” 

□ (Call -*• Call U Hear) 

“if Call is high, it will stay high until 

Hear is high” 

□ (Car// - oHear) 

“if Call is high, then sooner or later 

Hear will rise” 

□ (~ Call -» o ~ Hear) 

“if Call is low, then sooner or later 

Hear will fall” 

Research. G.V. Bochmann of the Uni¬ 
versity of Montreal, Canada, presented 
one of the first attempts to use temporal 
logic as a formalism to describe and rea¬ 
son about hardware. In his approach, time 
is linear and discrete. He presented some 
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Figure 7. A handshaking protocol. 



Figure 8. A traffic-light controller. 


of the axioms bound to the modalities he 
used, then described and verified an 
arbiter. Verification relies upon a kind of 
reachability analysis, in which possible 
states and transitions are generated and 
symbolically executed. 

M. Fujita, H. Tinker, T. Moto-oka, and 
S. Nishiyama of the University of Tokyo, 
Japan, presented an approach to formal 
verification based on linear temporal logic 
and Prolog. The domain of application is 
currently restricted to finite-state machines 
used to implement the synchronization 
part of a complex system. Implementa¬ 
tions are described in standard HDLs, 
such as HSL or a subset of DDL, at the 
gate or register-transfer level. Specifica¬ 
tions are expressed in temporal logic with 
weak and strong until (U) operators. 
Implementations are automatically trans¬ 
lated into C-Prolog clauses, while specifi¬ 
cations are transformed into state 
diagrams using temporal logic’s decision 
procedure. This state diagram and the 
implementation are simultaneously 
traversed to look for a counterexample, 
where negated specifications satisfy the 
implementation. Some features expedite 


the system’s efficiency, including filtering 
of descriptions, storing state transitions, 
and using external specifications. The 
authors used this approach for automatic 
synthesis of state diagrams starting from 
temporal logic specifications. 

Branching temporal logic example. 
Consider the expression of some safety 
and liveness properties for a traffic-light 
controller 8 (see Figure 8). The traffic-light 
controller is stationed at the intersection of 
a two-way highway going north and south 
and a one-way road going east. No turns 
are permitted. At the north, south, and 
east of this intersection, a sensor goes high 
for at least one clock cycle when a car 
arrives. When the intersection is clear of 
cross traffic, the controller raises a signal 
indicating that the car may cross the inter¬ 
section. Once the car has crossed, the sen¬ 
sor that indicated the arrival will go low. 
The sensors are named N, S, and E; the 
output signals for each end of the intersec¬ 
tion are N-Go, S-Go, and E-Go. 

A description in branching temporal 
logic follows: 

VG ~ (E-Go A (N-Go V S-Go)) 

“for every path in the future, at every 
node on the path, there will never be 
green signs in both directions” 

This formula is a safety property that is 
true if the controller does not permit col¬ 
lisions. 

The following liveness properties state 
that every request to enter the intersection 
is eventually answered, so the controller is 
starvation-free. If all three of these for¬ 
mulas are true, the controller is deadlock- 
free as well. 

VG(~ N-Go AN-*- W F N-Go) 

“for every path in the future, at every 
node on the path, if the light is red 
and there is a northbound car 
requesting to cross, then for every 
path there will be at least a node on 
the path where the N-Go signal will 
be high” 

VG(~ S-Go A S-* MFS-Go) 

“for every path in the future, at every 
node on the path, if the light is red 
and there is a southbound car 
requesting to cross, then for every 
path there will be at least a node on 
the path where the S-Go signal will be 
high” 


VG(~ E-Go A E~* VFE-Go) 


“for every path in the future, at every 
node on the path, if the light is red 
and there is an eastbound car request¬ 
ing to cross, then for every path there 
will be at least a node on the path 
where the E-Go signal will be high” 

3 F(N-Go A S-Go) 

“for some path there is a state on the 
path where both the N-Go and the S- 
Go signals will be high” 

Research. E.M. Clarke, B. Mishra, 
D.L. Dill, M. Browne, E.A. Emerson, and 
A.P. Sistla of Carnegie Mellon University, 
Pittsburgh, presented an approach and the 
supporting tool for formal verification of 
synchronous and asynchronous control 
parts of digital systems. Implementations 
are described by either structural HDLs or 
an ad hoc language called SML, for state- 
machine language. Specifications are 
expressed in the temporal domain using 
computation tree logic, or CTL, a branch¬ 
ing time propositional temporal logic. 
CTL extends all temporal logic operators 
to take into account the introduction of 
possibility in the future: a circuit may 
evolve along many possible paths. 
Implementations expressed in structural 
form are automatically transformed into 
a state-transition graph (a finite Kripke 
structure) by means of simulation. If the 
implementation is already expressed as a 
finite-state machine, the state-transition 
graph generation process is almost 
immediate. Verification relies upon state- 
graph transition, possibly exhaustive, 
looking for a counterexample of the spec¬ 
ification. 

The tool supporting this approach, 
called MC for model checker, comes in a 
C-language version and a Franz-Lisp ver¬ 
sion. Since state-graph complexity 
increases exponentially with the size of 
designs, the authors proposed multilevel 
verification to keep the task manageable. 
Lower-level modules are composed to 
yield complex ones, thereby shrinking 
complexity by restriction. In a later ver¬ 
sion, called EMC for extended model 
checker, the updated tool deals with a 
more expressive branching time temporal 
logic called CTLF. The authors have 
applied their approach to a FIFO cell and 
to an asynchronous communication inter¬ 
face adapter. 

Interval time temporal logic example. 
Consider the expression of a positive pulse 
signal 9 with quantitative timing informa¬ 
tion (see Figure 9). 
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The corresponding interval temporal 
logic formula looks as follows: 

X = 

[(x ~ 0 A minlen (/)); skip; 

[(x ~ 1 A minlen (m)); skip; 

[(x~ 0 A minlen (n))] 

The construct minlen (n) is true for an 
interval at least n units long. Skip is a con¬ 
struct to test for intervals having length 
one. 

Research. B. Moszkowski of the Uni¬ 
versity of Cambridge, United Kingdom, 
presented a general-purpose formalism to 
specify hardware behavior, called ITL for 
interval temporal logic. ITL is general- 
purpose because you can use it to describe 
register-transfer operations, as well as flow 
graphs and transition tables. ITL’s syntax 
allows variables, expressions, and for¬ 
mulas. Each formula is associated with a 
sequence of states (points in discrete time). 
A function maps variables, formulas, and 
states into data values. Through this map¬ 
ping function, it is possible to define when 
a sequence of states satisfies a formula. 
ITL is local in that truth or falsity of a for¬ 
mula depends only on the value the map¬ 
ping function returns on the first state of 
the interval. Some operators have an 
interval-dependent meaning, which distin¬ 
guishes ITL from all other temporal logic 
formalisms. 

Moszkowski presented Tempura, a 
logic programming language with imper¬ 
ative constructs for assignment, as a logi¬ 
cal consequence of his work. Tempura 
functions as a conventional programming 
language or as an HDL for structural 
descriptions. A ring network and a mul¬ 
tiplier exemplify its use in the hardware 
description domain. As a logic program¬ 
ming language, Tempura resembles Pro¬ 
log, but has no incorporated unification 
and backtracking facilities. It is supported 
by a software tool implementing its inter¬ 
preter. This evaluates formulas, splitting 
them recursively into values at present and 
next state, in a way similar to temporal 
logic’s decision procedure. 

Moszkowski did not present evidence 
for the utility of his approach in the 
domain of formal verification of hard¬ 
ware; rather, he claimed that such an 
extension would not be difficult. 

Within the major framework intro¬ 
duced by Moszkowski, T. Aoyagi, M. Fuj- 
ita, T. Moto-oka, S. Kono, and H. Tinker 
of the University of Tokyo presented 
Tokio, a concurrent logic programming 


language. Although based on Prolog, it 
extends it by incorporating local ITL con¬ 
cepts. Since Prolog lacks the concept of 
time, assignment occurs as a tricky side- 
effect. This is Prolog’s main disadvantage 
with respect to conventional programming 
languages. Tokio introduces a discrete 
time model, with intervals defined by their 
starting and final events. ITL operators 
have been added to Prolog, and the inter¬ 
preter can be directed to execute goals in 
specified intervals. The authors presented 
no examples of Tokio’s application to for¬ 
mal verification, but we expect them in the 
near future. 

Evaluation. Temporal logic substan¬ 
tially advances traditional logic because it 
can capture time and dynamic 
behaviors—essential features in hardware 
descriptions—with concise and clear nota¬ 
tion. For example, it avoids the introduc¬ 
tion of explicit time functions and time 
variables. Moreover, temporal logic is use¬ 
ful in different environments, such as pro¬ 
gramming, although within the domain of 
hardware verification no one has yet 
exploited its full power. Timing anoma¬ 
lies, races, and hazards could be described 
easily, but we are not aware of similar 
research efforts. 

A lively debate among temporal logi¬ 
cians focuses on the relative merits of lin¬ 
ear and branching time temporal logic. 
The common opinion is that linear time 
temporal logic has more expressive power 
and branching time temporal logic has 
more powerful decision procedures. The 
choice between the two strongly depends 
on the applications. 

Cross-fertilization with 
software verification 
techniques 

Since software verification is older than 
its hardware counterpart, one of the first 
approaches for hardware adapted some 
software verification techniques to the 
particular domain under consideration. 

Programming languages constitute 
immediately available description formal¬ 
isms. Although not, strictly speaking, for¬ 
mal systems, they have been extended for 
hardware description and verification in 
conjunction with logic. Most descriptions 
of hardware are procedural; that is, a locus 
of control governs the evaluation. This 
heavily restricts the application domain of 
such formalisms. In fact, they are used 



Figure 9. A pulse with timing details. 



Figure 10. A Muller C-element. 


only at very high levels of design, namely 
those in which behavior is described 
algorithmically. Procedural descriptions 
allow the expression of some useful fea¬ 
tures typical of a software verification 
environment, such as termination proper¬ 
ties, preconditions, and postconditions. 
Normally, you would resort to predicative 
forms to express these features, which play 
the role of specifications or properties, 
while procedural descriptions represent 
implementations. 

Examples. One example of the applica¬ 
tion of Floyd’s inductive assertion method 
considers the expression of preconditions, 
postconditions, and loop assertions on a 
Muller C-element 10 (see Figure 10). We 
can easily state the operation of the C- 
element. The device has two binary input 
signals, a and b, and a binary output sig¬ 
nal, c. The output becomes 1 whenever 
both inputs become 1; it becomes 0 when¬ 
ever both inputs become 0. Otherwise, it 
stays the same. Since no particular 
assumptions are made about the input sig¬ 
nals a and b, the corresponding assertion 
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<|> is true at every time t. Because the circuit 
has only one cycle, a single loop assertion 
yj suffices and is coincident with the out¬ 
put assertion to. The proof employs the 
STP theorem prover. 

= true 

co, +2 = yj, + 2 = 

if (a, = b,) then a, else to, 

Research. R.E. Shostak of SRI Interna¬ 
tional, Menlo Park, California, modeled 
hardware as a graph with circuit elements 
for nodes and signals for arcs. Each circuit 
element is characterized by a transfer 
predicate, which expresses how the ele¬ 
ment transforms its inputs to yield its out¬ 
puts. Assertions are placed on inputs, 
outputs, and loops. As in Floyd’s method, 
verification conditions are generated by 
tracing back output assertions to the 
inputs and comparing them with input 
assertions using the STP theorem-prover. 
To ease the task, acyclic subgraphs are 
extracted from the complete graph and 
verified one by one. Shostak’s examples 
concerned some analog and asynchronous 
circuits, without explicitly considering 
time or reporting any automation. 

A very similar approach taken by V. 
Pitchumani, E.P. Stabler, and Z.D. Umri- 
gar of Syracuse University, Syracuse, New 
York, featured assertions, preconditions, 
postconditions, and a theorem-prover. 
The authors used a register-transfer lan¬ 
guage similar to Pascal and AHPL to 
describe hardware. This language allows 
concurrent constructs, and the authors 
described proof methods for parallel con¬ 
trol sequences. The domain of application 
of such a method is limited to synchronous 
circuits. The authors reported no mechani¬ 
zation. 

An approach based on Floyd’s inductive 
assertion method but with interesting var¬ 
iations comes from M.C. McFarland and 
A.C. Parker of Carnegie Mellon Univer¬ 
sity, Pittsburgh. Instead of verifying that 
a design implementation complies with its 
specification, they considered a more 
general case. They demonstrated that cer¬ 
tain transformations used to optimize 
designs are correct, so that the behaviors 
of original and transformed designs are 
equivalent. 

McFarland and Parker used the descrip¬ 
tion language called ISPB, a subset of 
ISPS. ISPB is axiomatized and has a set of 
rules used to manipulate expressions. Like 
ISPS, it is procedural but allows concur¬ 
rent statements. The way hardware 


behaves is captured by its interactions with 
the environment, which the authors called 
events. Sequences of events represent his¬ 
tories, used to give meaning to descrip¬ 
tions. Specifications are expressed as 
behavior expressions, that is, regular 
expressions augmented by predicates. The 
system was developed within the Carnegie 
Mellon University Design Automation, or 
CMUDA, project. 

Evaluation. Applying software verifica¬ 
tion techniques to hardware suffers from 
some drawbacks. First, devices are 
described in a procedural fashion and only 
at very high levels of abstraction (algorith¬ 
mic and behavioral). Moreover, this 
approach follows closely the evolution of 
its software counterpart, including its dif¬ 
ficulties. Thus, such research represents a 
minority of the current efforts in this area. 

S imulation has evident theoretical 
limits, but thanks to the efficiency 
of its tools, it is widely used in com¬ 
mercially available systems. Although they 
overcome simulation’s nonexhaustivity, 
formal techniques introduce additional 
concerns: they need formal description 
and proof systems. 

Formal techniques are now mainly aca¬ 
demic efforts, with the majority of 
research efforts located in Europe. US and 
Japanese researchers seem to concentrate 
more on automated synthesis. 

Let us now analyze current work. It 
looks like a big research effort is under 
way: a lot of projects are already under 
development and new ones are continually 
being started. Nevertheless, it proves very 
difficult to benchmark different 
approaches, and not just because of the 
vast amount of material to take into con¬ 
sideration. We deliberately avoided 
presenting comparisons or figures lacking 
merit from a theoretical or practical point 
of view. The domains to which the authors 
applied their methodologies differ 
markedly, ranging from the switch to the 
system level. Each author tailored the for¬ 
mal system and proof method to his 
domain, sometimes losing generality and 
applicability. For example, formal systems 
especially intended to model synchronous 
circuits are not easily extendible to asyn¬ 
chronous ones, and vice versa. 

Another observation concerns the 
domain of application: many authors 
restricted their examples to “special ’’cir¬ 
cuits, that is, either circuits already well- 
suited for verification or old-fashioned 
gate-level designs, bound more to 


MSI/LSI than to VLSI technology. More¬ 
over, the authors seldom considered gate 
arrays and programmable logic devices 
despite their growing importance in the 
world of application-specific IC design, 
nor did they take into account low-level 
timing issues, such as races and hazards. 

From a practical point of view, formal 
techniques face a major limitation: the 
majority of approaches are purely the¬ 
oretic. Even when some software tool is 
implemented, it is in general a prototype, 
its performance is hard to evaluate, and it 
cannot be easily incorporated in commer¬ 
cial systems. 

Although formal verification tech¬ 
niques suffer from evident limits, we 
believe that they are important not only 
from a theoretical, but also from a prac¬ 
tical, point of view. The ability to verify a 
design implies understanding of its pro¬ 
found semantic meaning; this helps both 
manual design and automated synthesis. 
Tools are becoming more efficient as we 
gain in expertise and take advantage of 
recent developments in parallel processing 
and innovative architectures. Within a few 
years, perhaps five or six, we can hope to 
see commercial systems including formal 
techniques, although it is hard to believe 
that they will be general-purpose. 

Industry, abandoning its initial skepti¬ 
cism, is becoming more and more 
interested in formal verification, since it 
can guarantee correct designs and shave 
costly development time. Some major 
European manufacturers plan to include 
in their private CAD systems some of the 
formal verification tools currently under 
development. 

If formal verification keeps in touch 
with the latest developments in VLSI, so 
computer-aided design does not lag behind 
design, both Fields will benefit and contrib¬ 
ute significantly to the advancement of 
computer science. □ 
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An Exercise in 
Plausibility-Driven Design 

Alan R. Hooton, Tektronix Inc. 

Ulises Agiiero, Instituto Tecnologico de Costa Rica 
Subrata Dasgupta, University of Southwestern Louisiana 


I mproving the means of designing 
artifacts has been, and continues to 
be, the quest of many researchers in 
what Simon first termed the “sciences of 
the artificial.” 1 In the domain of com¬ 
puter systems, this pursuit has led to many 
new methods for developing a design, lan¬ 
guages for capturing the design, and tools 
for mechanizing parts of the design 
process. 2 ' 4 

(We should note here that when we use 
“design” as a noun, it denotes an explicit 
description or representation of the target 
artifact in some artificial, symbolic lan¬ 
guage. This representation serves as a blue¬ 
print, or an organized set of instructions, 
for either the physical implementation of 
an artifact or an abstract implementation 
in some other, lower-level symbolic lan¬ 
guage. When we use “design” as a verb, 
it refers to the intellectual processes and 
related activities involved in the produc¬ 
tion of such representations.) 

In spite of these advances, many signif¬ 
icant problems continue to plague the 
methodology of computer systems design. 
Our particular concerns in this article 
relate to the following aspects: 

(1) While it is a truism that design begins 
with some given requirements, the set of 
requirements (or goals) facing the designer 
are often specified imprecisely, ambigu¬ 
ously, and nonquantitatively. The causes 



The theory of 
plausible design can 
greatly benefit the 
designer, as 
demonstrated here by 
the design of a 
special-purpose 
multiprocessor. 


for this usually pertain to Simon’s notion 
of bounded rationality 1 —the fact that 
designers and their clients are limited in 
their capacities to make fully rational 
choices, decisions, or identifications dur¬ 
ing the initial development of require¬ 
ments. Thus, they may not be able to 
articulate all the requirements that the tar¬ 
get artifact must satisfy, or they may not 
realize at the beginning of the design how 
different requirements may interact with 
one another. Consequently, it may not 


even be possible to objectively determine 
whether or not a design satisfies the given 
requirements or, for that matter, what it 
would mean for a design to satisfy the 
requirements. 

Consider, as typical instances of such 
requirements from the domain of com¬ 
puter architecture design, the following: 
“the instruction set must efficiently sup¬ 
port high-level languages” or “context 
switching between tasks must be fast.” 
Obviously, an architecture can hardly 
satisfy such requirements unless one 
expends considerable effort in defining 
such concepts as “efficient support” or 
“fast context switch.” The designer—and 
the design process—must, therefore, be as 
much concerned with the elaboration, 
refinement, and disambiguation of 
requirements as with the development of 
the design itself. 

(2) In general, the design process 
involves making decisions that charac¬ 
teristically take the following form: 

• Given a number of interacting objec¬ 
tives or goals, how should these goals be 
prioritized? That is, how should one order 
decisions concerning a number of interact¬ 
ing components when the nature of the 
interactions is known only qualitatively or 
imprecisely? 

• Given a number of alternative choices 
(regarding a component of the target 
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Figure 1. The evolutionary structure of design processes. The solid arrows repre¬ 
sent the ordering of these steps, starting with Design. Dashed arrows indicate the 
influence of one step on another. For instance, the requirements influence both the 
design and the critical-test steps. 



Specification of an architecture 
in the architecture description 
language S*M 

I 

Compiler 

Code 

executed on 


CASE 


Figure 2. The role of CASE in simulat¬ 
ing architectures. 


artifact, for example) that are approxi¬ 
mately equivalent in terms of function, 
performance, or cost, but exhibit different 
trade-offs, which of these choices should 
be made? 

The second main implication of bounded 
rationality is that the ramifications of such 
decisions or a particular chain of such deci¬ 
sions can not always be predicted or com¬ 
prehended at the time the decisions are 
made. Thus, a design at any stage of its 
development must necessarily be regarded 
as a tentative proposal that may at any 


later stage be retracted or modified. 

Two important consequences arise from 
the circumstances stated in (1) and (2) 
above. First, we must necessarily view a 
design process (in general) as an evolution¬ 
ary process, characterized as follows. (We 
present a much abbreviated description of 
our evolutionary model of design here. See 
chapter three of Dasgupta 5 and especially 
his upcoming work 6 for more detailed dis¬ 
cussions.) 

At any stage of its development (includ¬ 
ing the stage at which we consider it “com¬ 
plete” or “final”), we view the design as 
a tentative or conjectural solution to the 
problem posed. The designer’s task in each 
cycle of the evolutionary process is to 
elaborate either the design or the require¬ 
ments so as to establish or converge to a fit 
between the two. Since we determine the 
adequacy of a design solely with respect to 
the requirements prevailing at that stage of 
the design, an integral part of each cycle of 
design evolution is the critical testing (for 
fit or misfit) of design against require¬ 
ments and the subsequent elimination of 
a misfit by modifying the design, the 
requirements, or both (see Figure 1). 

Misfit can arise from many causes. It 
can result from a design that is incomplete 
or incorrect relative to the requirements. 
Alternatively, the design may be in such a 
form that one can not show whether or not 
it satisfies the requirements—in which case 
the design may need refinement or speci¬ 
fication in a different form. Or possibly 
the requirements are stated in such a form 
that one cannot show that the design satis¬ 
fies or does not satisfy them—in which 
case the requirements may require refor¬ 


mulation or generation of new 
requirements. 

The nature of the critical testing phase 
may range from common-sense reasoning 
to the use of past data or research results, 
the use of controlled experiments (by simu¬ 
lation or prototyping), or formal mathe¬ 
matical techniques. 

Second, if you accept the evolutionary 
model of the design process as depicted 
here, you must also agree that the believ- 
ability or plausibility of a design depends 
on 

• the history of the design, where “his¬ 
tory’ ’ refers to the recorded sequences 
of design decisions and the cause- 
effect relationships between design 
decisions; and 

• the nature of the evidence used by the 
designer to justify design decisions 
and/or establish the fact that a design 
feature satisfies a particular set of 
requirements. 

Recently we proposed a design para¬ 
digm we call the theory of plausible design, 
or TPD, that addresses both these 
issues. 7,8 We use the term “design para¬ 
digm” to denote a particular methodolog¬ 
ical philosophy or approach to design that 
also serves as a useful abstraction of, or a 
schema for, a family of similar design 
methods. As we will show later, a design 
method based on TPD—a “plausibility- 
driven” design method—will not only 
prove instrumental in developing a design, 
but will also (1) generate and document 
explicitly the cause-effect relationships 
between design decisions and thus provide 
an explanation of why a particular design 
evolved in the way it did; and (2) document 
explicitly the nature and source of the evi¬ 
dence used by the designer in acquiring 
confidence in the design, thus establishing 
its “plausibility.” These two characteris¬ 
tics perhaps most distinguish TPD from 
other design paradigms. (Dasgupta’s 
upcoming work 6 will discuss and compare 
several prominent design paradigms.) 

TPD is a general paradigm applicable to 
any aspect or level of computer system 
design. Thus, we were interested in testing 
TPD’s viability and practicality by apply¬ 
ing it to a number of different, realistic, 
large-scale design problems. At about the 
time we were examining possible problem 
candidates, one of us (Hooton) was about 
to undertake the design of a special- 
purpose multiprocessor to serve as a com¬ 
puter architecture simulation engine. This 
machine, named CASE, would execute 
compiled versions of architecture specifi¬ 
cations written in the architecture descrip- 
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tion language S*M 9,10 and allow 
simulation of the operation and behavior 
of the specified architecture (see Figure 2). 
Since S*M descriptions of architectures 
would encapsulate parallelism (both 
implicit and explicit), a fast simulation 
engine would need parallel processing 
capabilities. 

The design of CASE seemed a most 
appropriate vehicle for both testing the 
viability of TPD and investigating its 
influence on the ‘ ‘shape’ ’ of a design. We 
thus decided that the development of the 
CASE design would be strictly plausibility- 
driven. We will now present (in tutorial 
style) some of the main features of CASE’S 
design as it evolved and, in the process, 
illustrate the practical application of the 
theory of plausible design. 

Theory of 
plausible design 

The theory of plausible design origi¬ 
nated from a concern about the informal, 
ambiguous, and imprecise nature of typi¬ 
cal design proposals in computer architec¬ 
ture. 3,8 Because of these characteristics, 
an architect’s claims concerning the capa¬ 
bilities and properties of an architecture 
are often viewed with a great deal of scep¬ 
ticism until and unless the design (and 
associated claims) are supported by an 
actual implementation of the architecture. 
In other words, computer architecture as 
an autonomous discipline holds a rather 
dubious status. With TPD we aimed to 
provide a systematic basis and a frame¬ 
work for establishing or enhancing the 
plausibility of an architectural design prior 
to its implementation. Consult Agiiero 
and Dasgupta 8 for further arguments on 
the motivation for, and benefits of, TPD. 

Constraints 

TPD centers around the notion that a 
design (of some system) is a specification 
of a set of interacting functional, struc¬ 
tural, and performance constraints that 
must be satisfied by an implementation of 
the system. We use the word “constraints” 
rather idiosyncratically here, to refer to 
properties or features exhibited in a design 
and to emphasize that these properties are 
constraints on the implementation of the 
design, not on the design itself. In TPD, 
the constraints, collectively, are the design. 

The following examples typify con¬ 
straints that might emerge during the 


design of a multiprocessor architecture: 

• The machine exploits possibilities for 
concurrent activity during the execution of 
a program. 

• The processor-memory interconnec¬ 
tion scheme is of the multiple-bus type. 

• The maximum throughput of the 
machine is one gigaflop. 

We can note the following remarks regard¬ 
ing the nature of constraints: 

(1) At the beginning of a cycle of design 
evolution (see Figure 1), some constraints 
will be postulated as desirable goals —that 
is, they constitute the requirements. On 
completion of that cycle (or a sequence of 
such cycles), the goal constraint should 
have become an actual feature of the 
design, or a design fact. The designer’s 
task is to transform (in the course of design 
evolution) all such goal constraints into 
(demonstrably plausible) fact constraints. 

(2) In the early stage of design, con¬ 
straints may be quite imprecise in their for¬ 
mulation. Indeed, most high-level goal 
constraints in complex systems design are 
imprecise. At some later stage of the design 
process, these original constraints will be 
defined in terms of more primitive and 
precise constraints. As we will show, this 
will be necessary to establish the original 
constraints’ plausibilities. 


Plausibility statements 

Constraints are packaged in the form of 
plausibility statements that allow reason¬ 
ing about the constraints using the rules of 
reasoning (“laws of plausibility”) 
provided in TPD. A plausibility statement 
is defined as a 5-tuple: 

S = < C, A, R, P, V> 
where 

• C is the non-null set of constraints 
whose plausibility is being established by S. 

• A is the knowledge base (which may 
include facts, theories, principles, and/or 
research results, as well as other con¬ 
straints belonging to the current design) 
used to assist in establishing C’s plausi¬ 
bility. 

• R denotes the relationships (between 
constraints appearing in A) that must be 
verified to establish C’s plausibility. It is 
expressed as a well-formed formula in 
predicate calculus. 

• P is the plausibility state in which C 
will be placed upon successful verification 
of S (see “Plausibility states” below). 

• V is the means employed to verify S 


(see “Means of verification” below). 

Thus, we interpret a given plausibility 
statement S as stating that C is in plausi¬ 
bility state P if it can be (or has been) veri¬ 
fied, using the verification means V, that 
R is in the plausibility state P. Several 
examples of plausibility statements appear 
later in the article. 

Plausibility states 

Intuitively, a plausible constraint is a 
constraint that we believe in because we 
have evidence that it exhibits certain desir¬ 
able properties. However, in the course of 
design, depending on the evidence at hand, 
the plausibility of a constraint may change 
from one design step to another. At any 
stage of the design, a constraint C may be 
in one of four plausibility states: 

(1) Assumed: no evidence against C’s 
plausibility exists. 

(2) Validated: significant evidence in 
favor of, and no evidence against, 
C’s plausibility exists. 

(3) Refuted: evidence against C’s plau¬ 
sibility exists. 

(4) Undetermined: the initial state of 
every constraint first introduced 
into a design. It signifies the situa¬ 
tion in which we do not know what 
counts as evidence for or against C’s 
plausibility (or where to look for 
that evidence). 

Figure 3 shows how the plausibility 
states relate to each other. These relation¬ 
ships provide for a number of interesting 
properties that prompt the “laws of plau¬ 
sibility.” 7,8 These “laws” are a logical 
framework we can use to control the effect 
that a change in the plausibility state of a 
constraint has on the state of other con¬ 
straints. 

Note that the first three of the above 
definitions are all given (at least partly) in 
terms of “evidence against.” This is moti¬ 
vated by the scientific objective of con¬ 
structing experiments that attempt to 
refute hypotheses, as opposed to con¬ 
structing experiments that attempt to con¬ 
firm them. Obviously, this follows from 
the fact that all confirming experiments 
become irrelevant as soon as a single refut¬ 
ing experiment succeeds. 

Means of verification 

Thus, the plausibility state is a function 
of the design step k at which the state is 
being established and the available evi- 
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C 2: CASE exploits possibilities for 
concurrent activity during the 
execution of specifications. 

A 2: S 4; S16. 

R2: C4AC16. 


V2: Evaluation of S4 and S 16. 
P2: Assumed. 


Figure 4. Example of a satisfiability- 
type statement. 


dence at that design step. We must note 
that what counts as evidence or significant 
evidence is not defined within TPD. The 
significance of evidence may indeed be 
subjective and, therefore, open to criti¬ 
cism. However, this is not a weakness of 
TPD itself, since what counts as evidence 
will depend on the nature of the design 
problem itself and the knowledge base (A 
in plausibility statements) surrounding the 
design problem. This is entirely consistent 
with the methodology of many sciences 
where what counts as evidence or the sig¬ 
nificance of evidence may be a matter of 
debate. If the evidence or its significance 
(as invoked by the scientist) is too subjec¬ 
tive, then it provokes criticism and dis¬ 
belief. Thus, to lend plausibility to a 
proposed hypothesis or theory, the scien¬ 
tist seeks better, preferably incontrovert¬ 
ible, evidence. So must the designer when 
establishing the plausibility of a design. 
The open and public expression of the 
nature of the evidence in a plausibility 
statement is exactly analogous to the pub¬ 
lic nature of the arguments advanced in 
support of a scientific proposition. 

The means of verification used to gather 
evidence in order to assign C to a plausi¬ 
bility state—the contents of the Kcompo- 
nent in the plausibility statement—may be 
any combination of the following: 

• Precise: the use of formal deductive 
logic. 

• Experimental: the use of experimen¬ 
tal methods such as simulation, emu¬ 
lation, or operation of prototypes. 

• Knowledge base: reference to the 

Figure 5. Example justification-type statement. data, analyses, theories, or results 


Undetermined 


Figure 3. Plausibility states and the relationships between them. 


C22: The interconnection scheme between the processing units and the global 
memory units, IN, is of the multiple-bus type. 

A 22: S*M specification of the mb_x stores and module multi_bus_arbiter, which 
describes IN; S22g; S22b. 

R 22: cond 1, where 

cond 1 = IN is a multiple-bus type interconnection scheme. 

V22: Examination of the S*M specification of the mb_x stores and module 
multi_bus_arbiter. 

P 22: Validated. 


(S22g) 

C22g: C22 is desirable. 

A 22g: Literature concerning the major interconnect schemes. 

R22g: cond l A cond 2, where 

cond 1 = multiple-bus interconnects can be easily designed to allow any 
amount of request concurrency desired (up to the amount a crossbar would 
offer). 

cond2 = they exhibit higher reliability than crossbar interconnects. 


V22g: Examination of the literature in A 22g. 
P22g: Validated. 
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reported in the research and technical 
literature. 

• Heuristic: approximate reasoning 
involving the use of heuristics. 

In essence, TPD allows a continuum of 
verification strategies to provide evidence. 
While we prefer verification using precise 
(logical) means to that using experiments, 
which is preferable to the use of heuristics, 
and so on, in any specific situation the less 
preferable means of verification may be 
the only one available or applicable. For 
instance, we may not be able to apply for¬ 
mal techniques or carry out the right kind 
of experiment. Obviously, that should not 
stop us from attempting to establish the 
plausibility of constraint, although the 
strength of the evidence is not what we 
would like. 


Types of plausibility 
statements 

A plausibility statement is usually of the 
satisfiability type. Such a statement shows 
the constraint C to be connected to the 
constraints in the R field by means of an 
“is satisfied by” or “if-then” relationship. 
An example of this appears in Figure 4, 
where the constraint C2 is satisfied by the 
constraints C4 and C16 according to the 
conjunction shown in R 2. Thus, if evi¬ 
dence can be found for C 4 and C 16 to be 
in the plausibility state Assumed, then C2 
will be placed in the Assumed state. 

By definition of a plausibility state¬ 
ment, 7 ’ 8 C2 will be in state Assumed if 
there is no evidence against R 2 being true. 
By the logic of plausibility statements, 
there is no evidence against R 2 being true 
if there is no evidence against C4 and there 
is no evidence against C16—that is, if it is 
verified that both C 4 and C 16 are in the 
Assumed state. 

TPD also recognizes a second kind of 
plausibility statement, referred to as a 
justification-type statement. Such state¬ 
ments document the desirability (or other¬ 
wise) of constraints. Consider Figure 5. 
Here, S22 is a satisfiability-type statement 
for the constraint C22. However, C22 has 
attached to it a justification-type con¬ 
straint, C22g, a statement concerning the 
desirability of C22. The justification-type 
statement S22g, stating that the constraint 
“C22 is desirable,” can be placed in the 
Validated state by showing that there is no 
evidence against, and significant evidence 
in favor of, R22g being true. Or, less for¬ 
mally, by showing that C22 is justified (as 


(SI) 

Cl: CASE efficiently supports the execution of architectural specifications writ¬ 
ten in S*M for the purpose of simulation. 

A 1: S2; S3. 

R 1: C2AC3. 

VI: Evaluation of S2 and S3. 

PI: Assumed. 


C2: CASE exploits possibilities for concurrent activity during the execution of 
specifications. 

C3: CASE provides specialized architectural support for the constructs in S*M 
that could not be efficiently supported using general-purpose approaches. 


Figure 6. The first three constraints and their relationship. 


a constraint or feature of the design) 
because of the conjunction of the cond 1 
and cond 2 conditions in R22g. 

Partitioning and 
constraint graphs 

In the process of developing a design 
using TPD, we can use an approach simi¬ 
lar to stepwise refinement, called partition¬ 
ing, to refine a (relatively) complex 
constraint Cinto two or more simpler con¬ 
straints Ci, C 2 .C„ such that we can 

infer the desired plausibility state of C 
from the plausibility states of the simpler 
constraints. A constraint graph con¬ 
veniently represents the effect of partition¬ 
ing pictorially. 

Jumping ahead a bit, the examples of 
Figures 7, 9, 10, and 12 show slightly 
different representations distinguishing 
between the “is satisfied by” relationship 
and the “is justified by” relationship. A 
solid arrow from Ci to Cj exists if Ci is at 
least partially satisfied by Cj. A solid line 
between Ci and Cik (where A: is a lowercase 
letter) indicates that Ci is (at least partially) 
justified by Cik. 


The design effort 
for CASE 

Designers undertake any design effort 
with some initial, fundamental motiva¬ 
tion; our effort was no different. The basic 
motivation for CASE was that it would 
provide for “fast” simulations. We 
extended this into the notion of “effi¬ 
ciency,” thus providing the overall 
requirement for the CASE design, as 
stated in constraint Cl: 

Cl: CASE efficiently supports the 
execution of architectural specifi¬ 
cations written in S*M for the 
purpose of simulation. 

Since we chose partitioning as the driving 
design methodology for this effort, Cl 
had to be partitioned. We decided that the 
“efficiency” constraint would be satisfied 
if two other constraints could be satisfied. 
The first of these deals with supporting 
concurrency; the second, with other types 
of specialized support. Figure 6 gives the 
state of the design at this stage. Note that 
we have identified what counts as evidence 
for or against the plausibility of C1: R 1 = 
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Figure 7. Early constraint graph. 



(S10*2) 


C10g2: 

CIO is desirable. 

A 10g2: 

Definition of S*M. 

R 10g2: 

condl, where 

cond 1 = clock processing should not have to wait for module processing 
units to complete. 

K10g2: 

Examination of the definition of S*M. 

P10g2: 

Refuted. 


Figure 8. Justification-type statement S10g2. 


C2 A C3. And, while there is certainly no 
evidence (significant or otherwise) in favor 
of R 1 being true, there is also no evidence 
against R 1; hence, we can assign Cl the 
plausibility state Assumed as shown in Fig¬ 
ure 6. 

We next decided that constraint C2 
would be partitioned; this led to con¬ 
straints C4 and C5, which stated, respec¬ 


tively, that module-grain concurrency and 
statement-grain concurrency would be 
supported. Since these constraints might 
appear arbitrary, and since granularity of 
concurrency is a controversial topic, we 
created justification-type statements for 
C4 and C5 to support their inclusion in the 
design. 

Next we partitioned C3. We immedi¬ 


ately saw that constraints C4 and C 5 
would involve special architectural sup¬ 
port. Thus, we required them to help 
satisfy not only C2, but also C3. After we 
partitioned C3 to include C4 and C5, the 
constraint graph took the form shown in 
Figure 7. 

We then partitioned C4 and C5. 
Although we partitioned each into only 
one new constraint, we expected that they 
would each be expanded in the future. As 
it turned out, we never partitioned C 4 fur¬ 
ther; we did expand C5, only to remove it 
at a later stage of the design. 

We continued partitioning in this fash¬ 
ion until we ran into a problem with the 
justification of a constraint (CIO) con¬ 
cerned with the support (in CASE) of tim¬ 
ing characteristics of architectures as they 
would be specified in an S *M description: 

CIO: Some processing of temporal 
information is done concur¬ 
rently with the execution of 
S*M modules. 

We created two justification-type state¬ 
ments in support of CIO. The problem 
arose with the second of these statements, 
S10g2, shown in Figure 8. 

The plausibility state PI Og2 in S10g2 
had initially been Assumed. Upon further 
investigation, however, we found evidence 
that cond 1 in R 10g2 would not hold under 
certain conditions. That is, we discovered 
that processing of clocks in an S*M 
description would, in fact, have to wait for 
the processing of S*M modules to com¬ 
plete. We found this evidence by direct 
examination of the definition of the S*M 
language. 9,10 P10g2 changed to Refuted, 
and we had to reconsider S10 in light of 
this change. 

Even though C10g2 entered the 
Refuted state, this did not automatically 
imply that CIO enters the Refuted state. 
Had a satisfiability-type relationship con¬ 
nected CIO and C10g2, then this would 
indeed have happened, because the laws of 
plausibility require that a constraint be 
placed in the Refuted state if another con¬ 
straint on which it depends is refuted. 

However, a justification-type relation¬ 
ship connects CIO and C10g2. Thus, 
whether the refutation of C10g2 requires, 
in turn, the refutation of CIO would 
depend on the significance attributed by 
the designer to C 10g2 as a justification of 
CIO. 

In this case, however, we decided to 
remove CIO from the design if C10g2 
could not be Assumed or Validated. The 
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Figure 9. Constraint graph at the end of design step 1. 


state of the constraint graph just prior to 
the removal of CIO appears in Figure 9. 
The effect of deleting CIO is the deletion 
of the portion of the design represented by 
the subgraph rooted at C10 (indicated by 
the dotted box in Figure 9). 

This example also illustrates the non¬ 
monotonic nature of the reasoning under¬ 
lying the design process. A mode of 
reasoning is termed monotonic if it reaches 
conclusions that are never retracted on the 
basis of new evidence. Design reasoning 
(along with many other forms of reason¬ 
ing) is, however, nonmonotonic in that 
conclusions reached on the basis of the 
available evidence may later be retracted 
in the presence of new evidence. Thus, in 
this example, the introduction of the con¬ 
straint C10g2 and its placement in the 
Refuted state caused us to reconsider C10 
and, consequently, to remove this con¬ 
straint from the design. 

The design of the CASE architecture 
continued in this manner and evolved into 
a multiple-instruction stream, multiple- 
data stream, or MIMD-style, multiproces¬ 
sor. Note that we presumed no such style 
at the start of the project. The choice of the 
MIMD style emerged as a result of the 


plausibility arguments put forth in the 
course of design. 

Eventually, we came to the stage at 
which work began on the design of the 
interconnection network. The root of this 
part of the design was constraint Cl8, 
previously created as a result of partition¬ 
ing C3: 

C18: An interconnection network 
(IN) exists between the process¬ 
ing units and the global memory 
units, and provides for some 
amount of concurrency among 
memory operations. 

To support this constraint, we decided 
to consider three styles of interconnection. 
We constructed constraints corresponding 
to each of these styles and partitioned C18 
to include them. However, the relationship 
between them was exclusive-OR (in con¬ 
trast to the usual AND relationship), 
indicating that eventually a choice would 
be made between these constraints. The 
plausibility statement for constraint C18, 
the three subconstraints, and the con¬ 
straint graph for this part of the design 
appear in Figure 10. In addition, we con¬ 
structed two justification-type statements 


for each of C20, C21, and C22. One state¬ 
ment in each pair discussed the desirable 
aspects of an interconnection scheme, 
while the other discussed the undesirable 
aspects. 

In the next step, we evaluated the alter¬ 
native choices for the interconnection 
scheme, using the justification-type plau¬ 
sibility statements as the basis for evalua¬ 
tion. We chose the multiple-bus approach 
specified in constraint C22 because we can 
easily redesign such interconnections for 
different levels of concurrency. We wished 
to build flexibility into the current design 
to reflect the likelihood that the CASE 
architecture would evolve in the future. As 
a result of this choice, we removed con¬ 
straints C20 and C21 (and their associated 
justification-type constraints)from the 
design. Figure 11 shows S 22, the plausibil¬ 
ity statement for C22, and its associated 
justification-type statements, while Figure 
12 shows the entire current constraint 
graph. 

In examining S22 note that cond 1 in 
R 22 is identical to the constraint C22. This 
simply indicates that C22 need not be par¬ 
titioned any further; rather, the constraint 
is sufficiently primitive for us to evaluate 
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(SI 8) 


C18: An interconnection network 
(IN) exists between the process¬ 
ing units and the global memory 
units, and provides for some 
amount of concurrency among 
memory operations. 

A 18: S*M specification of a set of 
entities, E, which describes IN; 

S 20; S2US22. 

R 18: (C20 © C21 © C22) A cond 1 
A cond2, where 
cond 1 = IN exists. 
cond2 = multiple memory 
operations may be occurring at 
the same time. 

K18: Evaluation of S20, S21, and 
S22, examination of the S*M 
specification of E. 

PI8: Assumed. 


C20: The interconnection scheme 
between the processing units 
and the global memory units, 
IN, is of the full-crossbar type. 

C21: The interconnection scheme 
between the processing units 
and the global memory units, 
IN, is of the multi-stage “ban¬ 
yan” type (omega, flop, delta, 
etc.). 

C22: The interconnection scheme 
between the processing units 
and the global memory units, 
IN is of the multiple-bus type. 



Figure 10. Interconnection scheme 
alternatives. 


its plausibility state using the S *M descrip¬ 
tion of the interconnection network. 

At this point, the emphasis of the design 
effort shifted. The design had progressed 
to the point where portions of it, most 
notably items relating to the multiple-bus 
interconnection scheme, could be specified 
in detail using the architecture description 
language S*M. 9 ' 10 Constructing this spec¬ 


ification was extremely straightforward, 
due to the explicit structuring of con¬ 
straints in the plausibility argument. These 
constraints identified major units in the 
architecture and specified clearly the 
behavior of these units. This resulted in an 
executable specification in S*M that we 
could then use to verify constraints related 
to behavior. 


(S 22) 

C22: The interconnection network (IN) between the processing units and the 
global memory units is of the multiple-bus type. 

A 22: S*M specification of a set of entities (E) that describe IN; S22g; S22b. 

R22: condl, where 

cond 1 = IN is a multiple-bus type interconnection network. 

K22: Examination of the S*M specification of E. 

P22 : Assumed. 


(S22g) 

C22g: C22 is desirable. 

A 22g: Literature concerning the major interconnect schemes. 

R22g : cond l A cond 2, where 

cond 1 = multiple-bus interconnects can be easily designed to allow any 
amount of request concurrency desired (up to the amount a crossbar would 
offer). 

cond2 = they exhibit higher reliability than crossbar interconnects. 

V22g: Examination of the literature in A 22g. 

P22g: Validated. 


(S22b) 

C22b: C22 is not desirable. 

A 22 b: Literature concerning the major interconnnect schemes. 

R22b : cond l, where 

cond 1 = multiple-bus interconnects require additional communications 
support to handle the multiple I/O paths visible to the memory units. 

V22b: Examination of the literature in A 22b. 

P22b: Validated. 


Figure 11. Plausibility statements associated with multiple-bus interconnects. 
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Figure 12. Full constraint graph after choice of the interconnection scheme. 


The verification effort 

As mentioned in our overview of TPD, 
the “V:” field of a plausibility statement 
identifies the method(s) used to verify the 
plausibility state of the associated con¬ 
straint. This is obviously an important 
piece of information. However, at times 
we need more than a simple naming of the 
method: How was the method applied? 
What steps were taken? What evidence 
was used and/or gained during the process 
of verification? 

The present version of TPD provides no 
way to include this type of information in 
plausibility statements. This is particularly 
unfortunate in our case, because a number 
of statements have simulation as the verifi¬ 
cation method. Obviously, the steps taken 
during the simulation are extremely impor¬ 


tant here; without this information, other 
practitioners could not possibly recreate 
our verification effort independently. Yet 
this capability for independent recreation 
of the verification effort (indeed, the entire 
design process) is one of the primary goals 
of plausibility-driven design. Thus, in this 
section we will further explain some of the 
verification methods used during the 
CASE design. 

Although we used a number of verifica¬ 
tion methods during the CASE design pro¬ 
cess, two are sufficiently general and 
simple that we can dispense with them 
here. The first of these, evaluation of sub¬ 
constraints is exemplified by plausibility 
statement S1 from the current design: 

(SI) 

C1: CASE efficiently supports the 


execution of architectural specifi¬ 
cations written in S *M for the 
purpose of simulation. 

A 1: S2; S3. 

/? 1: C2 A C3. 

VI: Evaluation of S2 and S3. 

PI: Assumed. 

In this situation, we evaluate S2 and S 3 to 
determine the plausibility states of C 2 and 
C3. Then the laws of plausibility provided 
in TPD 7,8 allow us to use those results to 
verify that R 1 does, in fact, hold. 

The second general verification method 
used is the examination of S*M descrip¬ 
tions. With this method, the designer 
examines the stated descriptions in an 
effort to convince him/herself that the 
conditions stated in the “ Rn field in 
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(S 18 ) 

C18: An interconnection scheme between the processing units and the global memory units, IN, 
exists, and provides for some amount of concurrency among memory operations. 

A 18: S*M specification of the mb_x: stores and module multi_bus_arbiter, which describes IN; S22. 

R 18: C22 A cond 1 A cond2, where 
cond 1 = IN exists. 

cond2 = multiple memory operations may be occurring at the same time. 

K18: Evaluation of S 22, examination of the S*M specification of the mb_x stores and module 
multi_bus_arbiter, simulation. 

P18: Validated. 


The simulation portion of this verification was very straighforward. Prior to starting the simula¬ 
tion, all of the fields in ‘mb_proc_request’ and ‘mb_mem_requested’ were set such that all processors 
were requesting a memory access, and all requests were to different memory units. The simulation was 
then started, with traces on ‘mb_proc_grant’, ‘mb_proc_switch_selects’, and ‘mb_mem_switch_selects’. 
It could be seen that the multi-bus arbiter allowed as many requests to begin as there are buses (four). 
Thus, multiple memory operations would be under way at the same time. 


Figure 13. Example of verification using simulation. 


question hold. As opposed to evaluation 
of subconstraints, this method is obviously 
less formal; verification rests solely on the 
judgement of the designer. Remember that 
this is not necessarily undesirable; all 
designs involve some amount of subjective 
judgement. Fortunately, TPD allows us to 
reveal where this subjectivity comes into 
play. Informal design methods usually do 
not accomplish this. 

In addition to these rather general verifi¬ 
cation methods, many plausibility state¬ 
ments required some kind of 
statement-specific verification method. In 
particular, some required executing the 
specification to exhibit behavior that 
would support one or more “Rn” fields. 
An example appears in Figure 13. The 
details are not important here, but note the 
comment following the plausibility state¬ 
ment. The simulation, or execution of the 
specification, is described in such a way that 
anyone could independently recreate it. 

W e asserted at the beginning of 
this article that, because of the 
evolutionary structure of the 


design process, the plausibility of a design 
is fundamentally a function of the history 
of the design, the cause and effect relation¬ 
ships between design decisions, and the 
nature of the evidence used by designers to 
justify such decisions. We have described 
a particular paradigm—the theory of plau¬ 
sible design—to achieve these objectives, 
and how we applied it to drive the partial 
design of a multiprocessor architecture 
called CASE. The full description of the 
CASE design appears in Hooton. 11 The 
history of the design, the causal relation¬ 
ships, and the kinds of evidence used were 
recorded by means of a structure of plau¬ 
sibility statements and the constraint 
graph. The laws of plausibility defined in 
TPD allowed for reasoning out the plau¬ 
sibility states of constraints from the plau¬ 
sibility states of other constraints on which 
they might depend. 

Although not shown here, the lowest 
level constraints in the CASE design were 
specified in S *M. We could then simulate 
such a specification using the S *M execu¬ 
tion environment 10 ; hence, any constraint 
appearing in a plausibility statement that 


had “simulation” in the “ V:” field could 
be subject to experimental verification. 
The obvious goal of plausibility-driven 
design is to place as many of the con¬ 
straints in the Validated state as possible. 
At any stage of the design process, how¬ 
ever, there will always remain constraints 
in the Assumed state because such con¬ 
straints can only be validated either by fur¬ 
ther refinement into still more primitive 
constraints or after an implementation has 
been completed. 

We must also point out that, in design¬ 
ing the CASE architecture, we used TPD 
somewhat less formally than we 
intended. 7,8 While the full power of TPD 
rests on formal usage, many benefits result 
from its use regardless of the extent of for¬ 
malism employed. These benefits include, 
for example, the explicit documentation of 
cause-and-effect relationships. Thus, an 
important result of this exercise is the 
demonstration that TPD provides these 
tangible advantages even when applied less 
rigorously than intended. 

In concluding we must, once more, 
emphasize the precise scope of plausibility- 
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driven design. Ideally, we would like to 
establish, with mathematical certainty, 
that the design satisfies given require¬ 
ments. For reasons indicated in the first 
section, such certainty cannot be guaran¬ 
teed in many (perhaps most) design situa¬ 
tions. TPD aims to establish confidence in, 
or the believability of, a design in terms of 
the plausibilities of its constraints, the 
reasoning history underlying the design, 
and the nature of the evidence invoked in 
the course of design. Such an explicit rec¬ 
ord of the logic and history of a particu¬ 
lar design may then also be subject to the 
scrutiny of others for purposes of evalua¬ 
tion, criticism, or modification. 

At present, two of us (Agiiero and Das- 
gupta) are coordinating efforts to develop 
automated tools for plausibility-driven 
designs. These tools will aid designers in 
the construction of constraint graphs, 
ensure consistency between the plausibil¬ 
ity states of the nodes of a graph, provide 
assistance regarding plausibility-driven 
design methods, record a design’s history, 
and provide other types of support to the 
designer. □ 
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Conference on Object Oriented Programming: Systems, Languages, and Applications 


September 25 - 30, 1988 
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The Conference 

OOPSLA'88 Is the third annual conference bringing together 
users, researchers, and implementers of object oriented sys¬ 
tems. We are presenting a program of tutorials, workshops, 
panel discussions, as well as exhibits, demonstrations, and video 
tapes. The technical program is a selection of some of the best 
current work on Object Oriented Programming. This conference 
is a forum for sharing experience and knowledge among both 
experts and newcomers to the field. Space Is limited, please 
register early. 

Conference Program 
Wednesday, September 28: 

Keynote Address - Speaker: Michael Stonebraker, Computer 

Science Division, University of California, Berkeley 

Technical Sessions- 1A: Implementation, 1B: User Interfaces, 2A: 

Extending Smalltalk 1,3A: Extending Smalltalk II 

Panels- 2B: Applying OO DBMS. 3B: Treaty of Orlando Revisited 

Exhibitor Reception 

Thursday, September 29: 

Technical Sessions - 4A: Database, 5A: Tools & Environments, 6A: 
Applications. 6B: Theory 

Panel-4 B: Object Oriented Knowledge Based Software Main¬ 
tenance 

Conference Banquet- Speaker: Mitch Kapor, On Technology, 
Inc. 

Friday, September 30: 

Technical Sessions - 7 A: Concurrency & Parallelism. 8A: Design 
Panels- 7B: Teaching OOP. 8B: OOP in Business 

Other Programs 

Workshops - A workshop program for professionals doing 
development and research within this field. Attendance Is 
limited. 

Videos - We are still soliciting video presentations which ex¬ 
emplify the characteristics of object oriented programming 
and system design. Presentations should cover recent or on¬ 
going work in the field. Direct submissions to Enrique Godreau, 
Xerox PARC. 3333 Coyote Hill Road. Palo Alto. 94304, (415) 494- 
4300. 

Exhibits - Exhibit days are Tuesday, Wednesday, and Thursday. 
For further Information on exhibits, contact Jim Salmons. JFS 
consulting. 345 West First Street. Suite 56. Tustln. CA 92680. (714) 
731-9022. 

Demonstrations- We are still soliciting demonstrations of object 
oriented systems and environments. Presentations should be 
made by members of the design or implementation teams, not 
by members of a marketing staff. Direct submissions to Dieter 
Zebbedies. Zebb/Hoff Machine Tool, Inc.. 9535 Clinton Road. 
Cleveland. OH 44144, (216) 631-6100. 


Conference Committee 

Conference Co-Chair 
Allen Otis 
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Larry Tester 
Apple Computer 
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Kurt Schmucker 
Apple Computer 


Operations & Local Arrangements 
Barbara Noparstak 
Dlgitalk, Inc. 

Treasurer 
Ellen Dorian 

Independent Consultant 
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MITRE Corporation 


Tutorial Program 
Introductory 

Session 1: Sunday, 9:00 - 12:00 Noon (Half Day) 

1 A: Introduction to Object Oriented Concepts 

Provides detailed information about object oriented program¬ 
ming and concepts. 

Masoud T. Milani and Raimund K. Ege, Florida Int'l Univ. 

Session 2: Sunday, 1:30 pm - 4:30 pm (Half Day) 

2A: Features of Object Oriented Languages 

Review of the underlying principles of object oriented program¬ 
ming, with the aim of showing both Its power and its potential pit- 
falls. 

Charles Hughes and Mahesh Dodani, The Univ. of Central Florida 
2B: C++and Object Oriented Design 

Aids the understanding of the new design concepts embodied in 
C++, including data abstraction, code reuse, and object oriented 
design. 

Alan Sloane, John Carolon, Adrienne Dockrell, Glockenspiel, Ltd. 

Intermediate 

Session 3: Monday, 9:00 am - 4:30 pm (Full Day) 

3A: Object Oriented Databases 

Presents the current research directions in object oriented data 
bases Including in-depth analysis and comparisons of various ap¬ 
proaches. 

Stanley Zdonik, Brown University 
3B: Object Oriented Design for Software Engineering 

Examines the relevance of object oriented techniques to the main 
goal of software engineering: improving the quality of software 
developed in production environments. 

Bertrand Meyer, Interactive Software Engineering, Inc. 

3C: Object Oriented User Interface Tooklts with MacApp 

Examines the use of objects in the construction of sophisticated 
user Interfaces, particularly MacApp. 

Kurt J. Schmucker, Apple Computer 

Session 4: Tuesday, 9:00 am - 12:00 (Half Day) 

4A: The Evolution and Design of an Object Oriented Database 
Management System 

Provides a comprehensive description of the design of an opera¬ 
tional object oriented database management system. 

Michael J. Caruso, Innovative Systems Techniques, Inc. 

4B: Building Display Interfaces to Object-Based Structures 

Illustrates the various concepts, issues, mechanisms, and options 
encountered in the construction of display Interfaces In object sys¬ 
tems. Shows how to choose and apply appropriate techniques for 
object interfaces. 

Mitchell L. Model, The Stepstone Corporation 

Session 5: Tuesday, 9:00 am - 4:30 pm (Full Day) 

5A: Specification and Design Methodologies in Support of 
Object Oriented Programming 

Presents methodologies for specification and design that en¬ 
courage object oriented design and implementation. The 
methodologies facilitate Identifying the objects in a system, deter¬ 
mining object decomposition alternatives, and selecting an Im¬ 
plementation approach. 

Grady Booch, Rational, David M. Bulman, Independent Consul¬ 
tant, Ivar Jacobson, Ericsson Telecom, Norman L. Kerth, University 
of Portland 

5B: Object Oriented Analysis: Theory and Practice 

Introduces and defines the concepts of Object-Oriented Analysis. 
To identify the capabilities required of a CASE tool. 

Stephen J. Mellor, Project Technology Inc., Alan Hecht, Cadre 
Technologies, David C. Tryon, Pacific Bell, Wayne R. Hywari, Project 
Technology Inc. 

Session 6: Tuesday, 1:30 pm - 4:30 pm (Half Day) 

6A: The Model-View-Controller (MVC) Paradigm for User Interfaces 
Explains Smalltalk's Model-View-Controller paradigm; Its structure, 
operation, use in the Smalltalk system, and application In the 
construction of new interfaces. Demonstrates the paradigm's lan¬ 
guage independence and conceptual generality. 

Mitchell L. Model, The Stepstone Corporation 








Tutorial Program Continued 
Advanced 

Session 7: Tuesday, 1:30 pm - 4:30 pm (Half Day) 

7A: Semantic Methods for Object Oriented Languages 

Presents the current state of the art in the semantics of objects and 
inheritance and related problems in programming language 
design from a mathematical viewpoint. 

Luca Cardelli, Digital Equipment Corporation, and John Mitchell, 
Stanford University 

7B: Object Oriented User Interfaces and Constraints 

Introduces the attendee to the use of constraints in the construc¬ 
tion of object oriented user Interfaces. 

Ralmund Ege. Florida International University and Robert Duisberg. 
Tektronix. Inc. 

Hotel Reservations 

OOPSLA '88 will be held at the Sheraton on Harbor Island in San 
Diego, California. To assure a confirmed room, call the hotel at 
(619) 692-2265 no later than August 19.1988. 

Daily room rates are applicable 3-days prior and 3-days after 
convention dates: Single $90.00, Double $100.00. All rates are 
subject to 7% Tax. A written confirmation will be mailed to you. 

Airline Information 

American Airlines is the official carrier for OOPSLA'88 and will 
offer special fares for attendees (and their families) to the 
conference. 

American Airlines will offer 5% off of Promotional fares, as long 
as all fare restrictions are met. This applies to First Class travel as 
well. 

A 40% discount off of the full coach fare for tickets issued 7 days 
prior to departure is also available. This special fare can be ex¬ 
tended for travel 7 days before or after OOPSLA. 

All reservations can be made by calling (800) 433-1790. Please 
specify OOPSLA's American Airlines STAR number SI 5424. All 
those who use the 800 number to reserve will be entered into a 
raffle for two free tickets on American within the continental U.S. 
and the Caribbean. American Advantage members will earn 
mileage as usual. Please support OOPSLA'88 by choosing 
American Airlines for your travel plans and by using the 
OOPSLA'88 STAR number. 

Conference Registration 

Registration forms will be processed only if accompanied by full 
payment In U.S. Dollars. Payments can be made by personal or 
company checks, money orders or cashiers checks. Checks or 
money orders must be drawn on or payable through a U.S. 
bank, and must have machine-readable account numbers. 
Please make checks payble to OOPSLA '88. Purchase orders, 
credit cards, and government vouchers cannot be accepted. 
Registration forms and payments submitted separately will be 
returned. No phone registrations can be accepted. 

Registration confirmation: Every effort will be made to notify 
registrants prior to the conference. Please allowthree weeks for 
confirmation of your registration after mailing, additional time 
for international mall. 

Refund: Refund requests must be by letter and postmarked on 
or before 22 August 1988. All refunds will be mailed out two 
weeks after the conference ends. 

Sellout Policy: All registrations will be processed on a first- 
come, first-served basis, based on date of receipt at the 
Chester P.O. Box. 
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Lisp on a Reduced- 
Instruction-Set Processor: 
Characterization and 
Optimization 

Peter Steenkiste and John Hennessy 
Stanford University 


hen designing a machine for a 
high-level language (HLL), 
we must decide how to divide 
the required functionality between hard¬ 
ware and software. The two current 
approaches use HLL-specific machines 
and reduced-instruction-set computing 
(RISC). 

In the HLL approach, the hardware 
directly implements many operations 
required in the language, usually with 
microcode. This can reduce the number of 
instructions required to encode a program 
and the amount of translation required by 
the compiler. The architecture is based on 
observations or measurements of program 
behavior at the source program level. 
Examples of HLL machines include the 
DEC VAX and direct correspondence 
architectures. 

In the last few years, several processor 
architectures have used the RISC 
approach. 1 The instruction sets of RISC 
machines are very simple, and the compiler 
translates down to the instruction set, 
which is usually implemented directly in 
hardware with little or no microcode. 
Examples of such processors are the IBM 
801 minicomputer, MIPS R2000, Stan¬ 
ford MIPS and MIPS-X 2 machines, Sun 
Sparc architecture, and Berkeley RISC 
and Symbolic Processing Using RISC 



The recent development 
of efficient Lisp 
compilers and 
reduced-instruction- 
set processors 
demands a reevaluation 
of the way Lisp is 
implemented. 


(SPUR) 3 machines. The development of 
RISC architectures was driven by data on 
the execution behavior of compiled HLL 
programs. Since the compiler favors sim¬ 
pler instructions, the architectures tend to 
implement only those simple instructions. 
Subroutines or macrocode sequences 
implement complicated instructions. 

Most RISC machines were designed 
using measurements on languages such as 
C, Fortran, or Pascal. Two important 


exceptions are the Smalltalk On A RISC 
(SOAR) processor and the SPUR chip, 3 
which is designed for the fast execution of 
Common Lisp. Both of these machines 
provide limited hardware support for their 
language environments. 

In determining which approach to use to 
implement Lisp, we faced several 
questions: 

• What does the execution behavior of 
Lisp programs look like, both as a func¬ 
tion of the frequency of occurrence of 
different operations and as a function of 
their cost? 

• What sort of hardware assistance 
might be appropriate for Lisp? Many 
existing Lisp machines have extensive 
hardware support for Lisp, yet little data 
is available on how that hardware is used 
and what performance benefits it has. 

• Would a simple RISC machine be a 
good host? 

• Can compiler optimizations or simple 
hardware additions improve performance 
substantially? 

To answer these questions, our strategy 
was to first collect data on what Lisp oper¬ 
ations are time-critical using a set of 10 
programs. We then used the same set of 
programs to evaluate and compare soft¬ 
ware optimizations and hardware support 
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for these important operations. We used 
MIPS-X as a typical example of a RISC 
processor, but our approach and most of 
our results are applicable to other architec¬ 
tures and languages. At the end of the arti¬ 
cle we compare the performance of 
MIPS-X for Lisp with other systems using 
the Gabriel benchmark set. 

Lisp implementations. Lisp is widely 
used in artificial intelligence and has some 
features that set it clearly apart from Pas¬ 
cal and C. Lisp employs runtime type 
checking and Lisp programs often do a lot 
of list searching and pointer dereferencing. 
The functional nature of the Lisp language 
also encourages the use of many small 
functions. Lisp programs execute in an 
environment that provides support for 
dynamic memory management, primitive 
operations on a number of data types, and 
runtime type checking. 

Lisp machines. Lisp machines address 
the performance and working-space limi¬ 
tations of early Lisp implementations on 
conventional processors. They typically 
try to optimize the execution of Lisp by 
building more functions into hardware; 
that is, they reduce the gap between the 
architecture and the Lisp source language. 
Some “Lisp machines” are really general- 
purpose processors that use special micro¬ 
code when Lisp is executed. Other proces¬ 
sors, such as the Symbolics 3600 and the 
Texas Instruments Explorer, are especially 
designed for Lisp. 7 

The Symbolics 3600 7 is a tagged archi¬ 
tecture in which the tags are used for the 
encoding of data types and the compact 
encoding of lists. The architecture is stack- 
based, and a number of Lisp functions, 
such as car, member, and generic arith¬ 
metic operations, are directly implemented 
in hardware or firmware. The processor 
also supports garbage collection. 

The TI Explorer II s is based on a very- 
large-scale-integration (VLSI) chip that 
contains an arithmetic logic unit (ALU), 
1,024 words of stack memory, 1,024 words 
of scratchpad memory used by the micro¬ 
code, and a dispatch buffer with branch 
tables. Lisp support includes parallel type 
checking facilities, garbage collection sup¬ 
port, and dispatch memory to implement 
multiway branches based on the data type. 
The architecture requires one megabit of 
microcode, which is kept off-chip. 

The SPUR project 3 at Berkeley is 
exploring the RISC approach to Lisp 
implementation. The SPUR chip is simi¬ 
lar to the Berkeley RISC-II processor, with 


some enhancements to support Common 
Lisp. The extensions include hardware 
tags, special conditional branches for tag 
checking, parallel type checking on car and 
cdr operation, support for integer arith¬ 
metic with runtime type checking, and 
support for garbage collection based on 
generation scavenging. Register windows 
reduce the register save/restore traffic 
generated by function calls. 

Lisp on general-purpose architectures. 
Lisp programs can be interpreted in the 
Lisp environment, but they are usually 
compiled to speed up their execution. The 
compilers in early Lisp systems often 
generated poor code, but more recent 
compilers are efficient. The Maclisp com¬ 
piler on the PDP10, for example, uses 
declarations to avoid runtime type check¬ 
ing and was optimized to execute arith¬ 
metic programs efficiently. One of the first 
efficient Lisp dialects was Portable Stan¬ 
dard Lisp. 4 

Scheme is a Lisp dialect that supports 
static scoping and tail-recursion elimina¬ 
tion. The Rabbit compiler for Scheme 
introduced some novel optimizations 
based on program source-to-source trans¬ 
formations; these compilation principles 
were later expanded in other Scheme 
compilers 5 and also in some Common 
Lisp compilers. The SI Common Lisp 
compiler, 6 for example, uses “standard” 
compiler techniques such as sophisticated 
register allocation, as well as optimization 
based on source-level transformations. 

The implementation of a number of 
efficient Lisp compilers proves we can exe¬ 
cute Lisp on a general-purpose architec¬ 
ture with reasonable performance. The 
development of RISC processors shows 
that a simple hardware can quickly execute 
programs written in a number of HLLs. 
Together, these two recent trends make it 
necessary to reevaluate the way Lisp is 
implemented. 


Characterization of Lisp 

A number of papers have presented 
instruction profiles for Lisp programs. 
Most of these measurements were done on 
microcoded Lisp machines to optimize the 
program encoding. As a result, the data is 
static, provides only frequency results with 
no timing measurements, or applies to 
stack architectures. This information has 
limited use when we try to identify time- 
critical operations in Lisp on a modern, 
register-oriented architecture. 


We used a set of 10 Lisp programs 
executing on MIPS-X to derive detailed 
dynamic profiling measurements. Fre¬ 
quency measurements at the MIPS-X 
assembly level give us a detailed picture of 
which operations are executed, because the 
instruction set of MIPS-X contains only 
simple, basic instructions. Since MIPS-X 
executes all machine instructions in a sin¬ 
gle cycle, we can get accurate timing meas¬ 
urements by instruction counts. 

The 10 programs are: 

• inter —a simple interpreter for a sub¬ 
set of Lisp used to calculate the tenth 
Fibonachi number and to sort a list of 
numbers. 

• deduce— a deductive information 
retriever for a database organized as 
a discrimination tree. 

• dedgc —the same program as deduce, 
but invoking a copying garbage col¬ 
lector in which it spends about 50 per¬ 
cent of its time. 

• rat— a rational function evaluator 
that comes with the PSL system. 

• comp —the first pass of the front-end 
of the PSL compiler. 

• opt —the optimizer added to the com¬ 
piler; uses lists and vectors. 

• frl— a simple inventory system using 
the frame representation language. 

• boyer —the boyer benchmark; a 
rewrite-rule-based simplifier com¬ 
bined with a dumb tautology 
checker. 9 

• brow —The browse benchmark with 
a reduced database; creates and 
browses through an Al-like database 
of units. 9 

• trav— The traverse benchmark with 
a reduced number of iterations; cre¬ 
ates and traverses a tree structure. 9 

Together, the programs include about 
11,500 lines of Lisp code without com¬ 
ments. Table 1 gives for each program the 
number of functions, lines of source code 
(without comments), and MIPS-X 
machine instructions after compilation. 
Each program includes the user program 
and the parts of the Lisp system modules 
(including the runtime type-checking mod¬ 
ules) used by the program. 

Portable Standard Lisp and MIPS-X. 

MIPS-X 2 is the successor to the MIPS 
processor. It has a simple instruction set 
with single-cycle execution for all instruc¬ 
tions. The processor has a load-store archi¬ 
tecture with 32 general-purpose registers. 
A CMOS implementation of the architec¬ 
ture has passed all functional tests and 
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Table 1. Information on the 10 test programs. 



Number of 
functions 

Lines of 
source code 

Words of 
object code 

inter 

64 

710 

1533 

deduce 

100 

900 

3419 

dedgc 

116 

1100 

4112 

rat 

148 

1900 

6315 

comp 

220 

2400 

9466 

opt 

226 

3500 

11121 

frl 

198 

2500 

11802 

boyer 

84 

1200 

1793 

brow 

91 

1000 

2296 

trav 

78 

810 

1673 
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might be needed if the branch does not go. 
MIPS-X also has a 512-word on-chip 
instruction cache. 

Portable Standard Lisp 4 is a relatively 
small Lisp dialect designed to allow an effi¬ 
cient implementation on a large number of 
architectures. PSL supports all the major 
data types supported by Common Lisp 
and is built around a portable compiler 
that operates in two steps. In the first 
phase, the Lisp source is translated into an 
intermediate language called cmacros— a 
machine-independent language for a 
virtual-register machine with 15 registers 
for parameter passing and locals. After 
some optimizations, the second phase 
expands cmacros into assembly language 
or machine code. One reason for PSL’s 
efficiency is its simple and fast function 
call convention: it passes parameters in 
registers and builds a minimal stack frame. 

Each data item in Lisp contains the data 
and a tag that encodes the data type. The 
PSL implementation on MIPS-X stores 
the tag in the five most significant bits of 
the word; the remaining bits contain either 
a pointer to the data or immediate data. 
We can identify four operations on an 
item: tag checking, tag extraction, tag 
removal, and tag insertion. To check a tag, 
we must isolate it from the information 
part using a tag extraction operation. We 
do this by shifting the tag to the least sig¬ 
nificant bits using a logical shift. Similarly, 
the tag must be removed before the data 
can be used. This involves masking out the 
tag with a mask kept in a designated reg¬ 
ister. In the last operation we insert a tag 
in a newly created data object. The term 
tag handling refers to all four operations. 


Figure 1. Dynamic instruction profiles for Lisp and Pascal. 


runs at 20 megahertz, which will sustain 
about 13 million instructions per second. 

One of the main goals of the MIPS-X 
design is to reduce cycle time as much as 
possible, so simple instructions can execute 
very quickly. In comparison with MIPS, 
the instruction set has been simplified even 
further: MIPS-X supports only one 
addressing mode (base plus displacement), 
and instructions take only registers as 
arguments; immediates must be loaded in 
a register with a special instruction. Such 
simplifications slightly increase the num¬ 
ber of instructions needed for some oper¬ 


ations, but simulations show the effect is 
small compared with the reduction in cycle 
time. 

Besides traditional delayed branches, 
which have two delay slots, MIPS-X also 
has squashed branches that only execute 
the instructions in the delay slots if the 
branch goes. Otherwise, the instruction’s 
effects are nullified and the delay cycles 
wasted. This second type of branch allows 
the reorganizer to eliminate more idle 
cycles, because instructions from the 
branch target can be moved in the delayed 
slots, even if they overwrite registers that 


Frequency measurements. Figure 1 
breaks down the instructions executed by 
our set of Lisp programs into five major 
instruction groups and compares the 
results with similar measurements for five 
large, optimized Pascal programs. The 
results are very similar: ALU instructions, 
(local) branches, and memory accesses 
comprise roughly the same percentage of 
instructions, but Lisp programs execute 
more jump instructions than Pascal pro¬ 
grams (8.6 percent versus 4.8 percent). 
Jump instructions implement function 
calls and returns. The Lisp numbers are 
consistent across all 10 test programs; the 
standard deviation ranges from 1.6 per¬ 
cent (for jumps) to 3.8 percent (for ALU). 

Further analysis of the instruction fre¬ 
quencies shows that the group of ALU 
instructions in Lisp is dominated by logi¬ 
cal and shift instructions (35 percent arith- 
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metic, 49 percent bit-field), but by 
arithmetic instructions in Pascal (75 per¬ 
cent arithmetic, 13 percent bit-field). This 
is no surprise, given that tag handling 
operations are implemented with bit-field 
instructions. 

Tag checking is very important in 
Lisp—about 5 percent of all instructions 
executed are conditional branches related 
to tag checking, corresponding to 40 per¬ 
cent of all conditional branches. A break¬ 
down of the memory references according 
to what part of the memory they access 
shows that 55 percent of all memory 
accesses reference the stack. These stack 
references correspond to 22 percent of all 
instructions executed. About 20 percent of 
the references access the heap, and 25 per¬ 
cent access global user or system variables. 
We can reduce global accesses by about 30 
percent by keeping the heap fill pointer 
and a pointer to the heap upper bound in 
a register. 

Branches, jumps, loads, and stores 
account for 63 percent of the instructions 
executed in Lisp and 58 percent in Pascal. 
In MIPS-X, single-cycle execution with 
delayed branches and software pipeline 
scheduling speed up these instructions. In 
implementations of non-RISC architec¬ 
tures, such as the VAX-11, these instruc¬ 
tions are a lot more expensive than ALU 
instructions. The similarity in the dynamic 
instruction profiles for Lisp and Pascal 
suggests that most MIPS-X features would 
not change if Lisp programs were included 
in the set of programs used in the MIPS- 
X design. 

Where does Lisp spend its time? We 

express the cost of Lisp operations as a per¬ 
centage of the total execution time of the 
programs, including any idle cycles 
associated with the operation. For exam¬ 
ple, the cost of a tag check includes one 
cycle to extract the tag, one cycle for the 
conditional branch, and possibly one or 
two cycles for idle or squashed delayed 
slots. Since branches, loads, and stores on 
MIPS-X are comparatively cheaper than 
on more traditional architectures, such as 
the VAX, we would need to adjust the fol¬ 
lowing results to apply to other 
architectures. 

Figure 2a gives the cost of a number of 
Lisp source-level operations. List opera¬ 
tions are important in our set of programs: 
car/cdr and cons without garbage collec¬ 
tion cost 18 percent and 11 percent, respec¬ 
tively. Arithmetic (6.4 percent) and vector 
(5.2 percent) operations consume less 
time. Of course, these numbers are pro- 





Figure 2. Cost in percent of execution time of (a) high-level operations and (b) low- 
level operations. 
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gram dependent since they depend on the 
data types. Type-checking operations 
specified in the source program account 
for 11 percent of the execution time. The 
fairly high cost of comparisons with NIL 
and of copying NIL into a register (3.4 per¬ 
cent) indicates that the allocation of NIL 
to a register is an important optimization, 
especially for a machine without versatile 
long immediates. Function calls and 
returns other than the ones used in vector, 
arithmetic, and cons operations account 
for 20 percent of the execution time. 
Accessing local variables allocated on the 
stack costs 17 percent. 

Most of the operations in Figure 2a are 
implemented as a sequence of more prim¬ 
itive operations at the MIPS-X assembly 
level. As shown in Figure 2b, we found 
three basic operations at this lower level 
responsible for more than 60 percent of the 
execution time: function calling and 
returning (24 percent), stack accessing (22 
percent), and tag handling (21 percent). 
The stack accesses mainly save registers 
across function calls. The cost of function 
calling and stack accessing includes the 
cost of storing and retrieving the return 
address; it accounts for 4.6 percent of the 
execution time (21 percent of the stack 
accesses). PSL uses a cheap function call 
convention, so we expect the cost of func¬ 
tion calling to be even higher on many 
other Lisp systems. 

These three time-consuming low-level 
operations are attractive targets for 
optimization, since their high cost makes 
a large speedup possible. Of the three oper¬ 
ations, only tag handling is Lisp-specific. 
Function calling and stack accessing are 
common in other languages, and our 
optimizations can also be applied there. 

Lisp programming environments pro¬ 
vide the flexibility to redefine functions at 
runtime. Unfortunately, function calls are 
expensive: more than 40 percent of the 
time is spent on the function call itself or 
on stack accesses that save and restore the 
contents of registers across function calls. 
Function calls are closely tied to the debug¬ 
ging environment, and several of our 
optimizations will reduce the flexibility of 
the environment, because groups of func¬ 
tions (modules) have to be compiled 
together, making redefining functions and 
tracing harder. 

Using different levels of optimization 
gets around this problem. During the 
development stage of a program, when a 
powerful programming environment is 
important, we can compile functions 
individually and use function calls that 



Lisp programming 
environments provide 
the flexibility to 
redefine functions at 
runtime. 


provide a lot of information to the debug¬ 
ger. When the program is ready to be given 
to other users, it can be compiled using all 
optimizations. 

The implementation of 
tags in Lisp 

The issue of safety versus speed in Lisp 
is particularly interesting. Lisp machines 
have special hardware for tags, so runtime 
type checking usually does not slow down 
program execution. On stock architec¬ 
tures, the programmer has the choice 
between unsafe but fast execution without 
type checking, and safe but slower execu¬ 
tion with runtime type checking in 
software. 

The cost of tag handling. Because the 
amount and implementation of runtime 
type checking strongly influence the num¬ 
ber of tag-checking operations executed, 
we first optimized the type-checking oper¬ 
ations by replacing the general, machine- 
independent PSL routines with optimized 
MIPS-X assembly routines. These optimi¬ 
zations are similar to those in a number of 
modern Lisp systems and machines, so our 
numbers should be representative for a 
large number of optimized Lisp systems. 

We can sometimes do some type check¬ 
ing at compiletime, when the programmer 
uses variable declarations or the compiler 
does type deduction based on the program 
context. When the type is known at com¬ 
piletime, the compiler can use an operator 
that does not do runtime checking, while 
still guaranteeing the correctness of the 
operation. The programmer could also 
compile his or her program “for speed,” 
in which case no type checking is done and 
type errors can have very unpredictable 
effects. Since the amount of runtime type 
checking in a program can vary widely, we 
will present data for programs with no type 


checking and programs with full runtime 
checking. The actual numbers for a spe¬ 
cific program lie between these two 
extremes. Adding runtime checking 
increases the execution time of our set of 
programs by 25 percent on average. 

Figure 3 summarizes the cost of the 
different tag-handling operations. Tag 
insertion consumes 1.5 percent of the exe¬ 
cution time—it is not a very critical oper¬ 
ation. Tag removal accounts for 8 percent 
of the execution time, and tag extraction 
accounts for between 4 percent and 11 per¬ 
cent, depending on how much type check¬ 
ing is done at runtime. The tag for integers 
is the sign extension of the sign bit, so oper¬ 
ations on integers require no tag removal. 
The cost of tag checking, which includes 
the cost of tag extraction, ranges between 
11 percent and 24 percent. When runtime 
checking is switched on, the number of 
tag-extraction operations, and thus the 
number of tag-checking operations, 
increases by an amount about equal the 
number of tag-removal operations. This is 
what one would expect—with full runtime 
checking, each data item is checked and its 
tag removed before the item is used, so the 
frequency of the two operations should be 
the same. 

Although bit-field operations are not 
common in Pascal, MIPS-X has a full set 
of logical instructions and shifts (with con¬ 
stant offset). Because the location of the 
tags is fixed, tag extraction and tag 
removal can be done in a single cycle. 
Some architectures, such as the VAX-11, 
have instructions that compare an arbi¬ 
trary bit-field with an immediate or a value 
in a register. Such instructions eliminate 
the need for tag extraction, but they have 
to be faster than a sequence of simpler 
instructions to yield improved perfor¬ 
mance. Cycle time and chip area consider¬ 
ations make these instructions expensive to 
implement on MIPS-X. Tag insertion 
requires two cycles on MIPS-X, but hav¬ 
ing a one-cycle tag insert, as would be pos¬ 
sible with more powerful bit-handling 
instructions, would make little difference 
in performance (less than one percent) 
since tag insertions are not frequent. 

Better tag implementations. To reduce 
the cost of tag handling still further, we 
could include hardware support, ranging 
from simple tag stripping to full automatic 
tag checking. Figure 4 shows the speedup 
for a number of different tag implemen¬ 
tations, compared to the standard tag 
implementation described in the subsec¬ 
tion “Portable Standard Lisp and MI PS- 
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X.” The first entry is an improved soft¬ 
ware implementation. The data part of 
most Lisp objects contains a pointer to the 
actual data, and tag-removal operations 
are used to create valid memory addresses. 
The MIPS-X memory system ignores the 
bottom two bits of addresses. If these bits 
are used for tag encoding, no tag removal 
is necessary when a data item accesses 
memory, which is almost always the case. 
By using a special tag encoding, we can use 
the bottom three bits for the tag without 
needing any tag removal for most data 
types. 10 This software tag implementation 
speeds up our programs by 6 percent on 
average. 

All other implementations in Figure 4 
require hardware support. The second 
implementation (no tag extraction) 
assumes the presence of a conditional 
branch that only looks at the tag part of the 
word. Such an instruction eliminates the 
need for tag extraction and speeds up our 
programs by 4 percent to 9 percent. This 
hardware would be relatively easy to add 
because the exception handling of the 
processor is not affected. The third entry 
combines the effects of the first two 
optimizations; the resulting speedup 
ranges from 9 percent to 14 percent. 

The fourth and fifth bars assume the 
MIPS-X instruction set plus hardware to 
do tag checking in parallel with other oper¬ 
ations. The hardware compares the tag 
value of the operands with an expected tag 
value and generates a trap if they differ. 
This hardware only speeds up programs 
that do runtime (error) type checking on 
primitive operations. The last entry com¬ 
bines all the architectural extensions and 
results in a speedup ranging from 9 percent 
to 22 percent, depending on how much 
runtime checking is done. This should be 
compared with the 6 percent gain from a 
better software implementation. The pay¬ 
off from hardware support of tag handling 
depends strongly on how much runtime 
checking is required. 


The cost of function 
calls 

We can implement the simple calling 
convention used in PSL very efficiently 
with the MIPS-X instruction set. A func¬ 
tion call requires four instructions in the 
calling function: 

• A jspci (jump to a location specified 
by register + offset and save the 
address of the next instruction to be 


executed in another register) for the 
control transfer. 

A store to save the return address on 
the stack. 

An addi (add-immediate) to build the 
stack frame before the call. 

Another addi to remove the stack 
frame after the call returns. 


The store and one addi always fit in the 
two delay slots of the jspci, so there is no 
CPU idle time associated with a function 
call. Some calls require an extra load to 
place the starting address of the called 
function in a register. Function calls con¬ 
sume about 13 percent of the total execu¬ 
tion time (see Figure 5). 


] Without runtime checking 
] With runtime checking 
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Figure 3. The cost of tag handling operations as a percentage of the execution time. 
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Figure 4. Speedup for a number of tag implementations in percent. 
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Figure 5. Allocation of time spent on calls, returns, and tail-transfers, as a percentage of all instructions. 


A return-from-function call requires a 
load of the return address in a register, fol¬ 
lowed by an indexed jump for the control 
transfer. The load has one delay slot and 
the jump two, so a return will take from 
two to five cycles depending on how many 
delay slots the reorganizer can fill with use¬ 
ful, unrelated instructions. The two jump- 
delay slots are hard to fill and are only used 
in 45 percent and 25 percent of the cases, 
respectively. These idle cycles are not a 
result of the architecture; almost all 
machines will have to wait for a memory 
access. A return takes 3.4 cycles on 
average. 

In PSL and other Lisp dialects, tail- 
recursion elimination optimizes all calls 
immediately followed by a return. A self¬ 
recursive call is replaced by a local branch, 
and recursion is converted into iteration. 
A call to a different function is replaced by 
a nonlocal jump, or tail-transfer, to the 
entry of the called function. The function 
that is the target of the jump will use the 
stack frame and the return address of the 
calling function, thus eliminating a return 
and the building of a stack frame. The cost 
of a tail-transfer includes one jspci for the 
control transfer and possibly one or two 
idle delayed slots. Figure 5 shows this cost. 

The last section of Figure 5 summarizes 
the cost of function invocation. Of the 
total time spent on calls and returns, about 
35 percent is used to store the return 
address on the stack and retrieve it before 
the return. About 25 percent is used to 


build and remove the stack frame, and the 
remaining 40 percent is used for the con¬ 
trol transfer. We can reduce the function 
call cost in two ways. First, we can reduce 
the cost of individual calls by eliminating 
unnecessary stack building and return 
address loads and stores, which account 
for more than 50 percent of the function 
call cost. Second, we can eliminate func¬ 
tion calls through function integration 
(inline expansion). 

Speeding up individual function calls. 

With the calling convention used by the 
MIPS-X compilers, the calling function 
builds the stack frame of a function. How¬ 
ever, some functions can do all their work 
in registers with no need to build a stack 
frame. We changed the calling convention 
so that the return address is passed in a reg¬ 
ister and the stack frame is set up by the 
called function, if it needs one. This con¬ 
vention is similar to that used in many 
Scheme systems. 

Reducing the cost of individual function 
calls eliminates about half of the stack 
frame addi and two-thirds of the return 
address loads and stores. However, an 
increase in the no-op frequency undoes 
almost half of this gain, yielding a speedup 
of only 3.6 percent on average. This 
increase in no-op frequency occurs 
because, with the new calling convention, 
the building of the stack frame cannot be 
packed in the delayed slots of the function 
call. It is hard to provide additional hard¬ 


ware support for function calls, since con¬ 
trol transfers and memory accesses 
dominate the cost. 

Optimizing calls to the runtime system. 
Lisp programs spend about 52 percent of 
their time in the underlying Lisp system. 
Also, 64 percent of all the executed calls 
access Lisp system functions. 11 This indi¬ 
cates that an efficient implementation of 
the Lisp system is critical for performance. 
We rewrote and optimized three groups of 
time-critical system routines, avoiding 
function calls whenever possible: 

• cons —PSL allocates list cells using a 
function call, requiring 19 cycles on MIPS- 
X. In-lining the operation, and keeping the 
top-of-heap pointer and the pointer to the 
heap upper bound in registers, reduces the 
cost to five cycles. 

• Generic arithmetic routines—We 
changed these to check specifically for 
integers in-line, and to call a general type- 
dispatch routine only if this test fails. Since 
operands are almost always integers, the 
more expensive type dispatch is usually 
avoided. This reduces the cost of a generic 
operation by about 35 percent when the 
operands are integers. 

• Vector accesses —We wrote these rou¬ 
tines so that taken branches, which MIPS- 
X favors, correspond to the non-error 
case. Vector access routines are invoked 
using fast function calls that do not build 
a stack frame. 
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Combined, these optimizations reduced 
the execution time of our programs by 17 
percent. Half of this gain comes from the 
reduction in the function call frequency or 
cost. Although optimizing the system 
functions increased the code size by 9 per¬ 
cent, the miss rate in the MIPS-X on-chip 
instruction cache actually decreased for 
most programs—the average miss rate 
dropped from 11.4 percent to 9.8 percent. 
The reason for this decrease is that after 
merging, the basic blocks have become 
slightly larger on average, thus making 
better use of the 16-word cache lines. 12 
When cache effects are included, optimiz¬ 
ing the system functions gives a speedup of 
19 percent. 

Merging under compiler control. Func¬ 
tions are a useful tool in structuring pro¬ 
grams, but they can be expensive, both 
because of the call overhead and because 
they prevent optimization. Several lan¬ 
guages provide macros or in-line direc¬ 
tives, which allow the programmer to 
specify code segments that will be merged 
each time they are invoked, so there is no 
runtime overhead. Although opencoding 
under control of the programmer is useful, 
having the compiler automatically in-line 
small functions is more desirable. 

To try out this idea, we added a function 
integrator to the PSL compiler. The 
integrator decides on a call-by-call basis 
which calls should be merged. Recursive 
calls can be in-lined a limited number of 
times by unrolling the recursion. The 
integrator accepts two important 
parameters: the maximum size of the 
largest function that should be considered 
for merging and the number of times 
recursive functions should be unrolled. We 
included in the evaluation the cost of han¬ 
dling misses in the MIPS-X on-chip 
instruction cache to more accurately 
reflect the true savings possible with this 
optimization. Two words are fetched on a 
miss, and the penalty is two cycles. 

We evaluated several merging 
strategies 12 and found the best was to in¬ 
line all calls to functions shorter than some 
cutoff length, but not to in-line any recur¬ 
sive calls. Recursive calls are often 
executed repeatedly, just like loops, and 
unrolling recursion spreads out the area of 
activity. Given a small cache (512 words 
for MIPS-X), the decreased locality of an 
unrolled recursive function increases the 
cost of cache misses by more than its sav¬ 
ings in call overhead. Because Lisp pro¬ 
gram execution is more often controlled 
through recursion than through itera¬ 


tion, 12 and loops often are executed only 
a small number of times, a merging 
strategy that concentrates on the most fre¬ 
quently executed function calls by only 
merging calls inside loops is very 
ineffective. 

Figure 6 summarizes performance 
results for nonrecursive merging. The x 
axis indicates the maximum function size 
merged, so increasing values correspond to 
more aggressive merging. Figure 6a shows 
the decrease in instructions executed with 
merging. The speedup increases quickly 


when merging small functions, but the 
incremental payoff decreases with more 
aggressive merging. Figure 6b shows the 
ratio of the code size after and before 
merging. Merging small functions has lit¬ 
tle impact on program size, but code size 
increases rapidly when larger functions are 
merged. The instruction miss rate (see Fig¬ 
ure 6c) drops slightly when small functions 
are merged, due to an increased locality, 
but increases with more aggressive merg¬ 
ing as a result of the code size increase. Fig¬ 
ure 6d combines the effect of Figures 6a 




Figure 6. Results for nonrecursive merging: (a) speedup (ignoring cache effects); (b) 
code size (relative to no merging); (c) cache miss rate; and (d) performance (includ¬ 
ing cache efforts). 
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and c, showing that the performance goes 
through a maximum. 

Performance speeds up 6 percent due to 
nonrecursive merging. There are several 
reasons for this rather modest increase. 
First, we excluded as candidates for merg¬ 
ing those system function calls that were 
optimized in the previous subsection; 
speedup increases to 24 percent if we 
include the effect of their optimization. 
Recursive calls, which account for 18 per¬ 
cent of the calls, are also not candidates for 
merging. After eliminating the “pre¬ 
integrated” system calls and the recursive 
calls, only half of all calls could potentially 
be merged. The small MIPS-X on-chip 
instruction cache that heavily penalizes 
code size increases also limits speedup. 

Interprocedural register 
allocation 

Most compilers do register allocation on 
a per-function basis, and live registers have 
to be saved on the stack before function 
calls. Copying values between registers 
and the stack accounts for 22 percent of 
the instructions executed in our set of Lisp 
programs. High register save/restore traf¬ 
fic rates have also been observed in other 
languages. 13 The high frequency of func¬ 
tion calls in structured programming lan¬ 
guages explains why per-function register 
allocation cannot effectively use large reg¬ 
ister files. This is especially true for Lisp, 
which has a higher function-call fre¬ 
quency. One solution is interprocedural 
register allocation, which makes it possi¬ 
ble to keep variables in registers across 
function calls. 

Interprocedural register allocation aims 
to minimize execution time by allocating 
program variables—ideally, the most fre¬ 
quently used ones—to registers. We can 
obtain estimates for the usage frequencies 
of variables from static program analysis 
or dynamic profiling information. 

We implemented an algorithm that does 
not try to obtain an optimal allocation of 
variables to registers, but relies on a heu¬ 
ristic with a good average performance 
and a small compile-time cost. The com¬ 
piler compiles the functions following their 
depth-first ordering in the call graph and 
keeps track of the registers used by each 
function. When functions are compiled in 
this order, the register allocator always 
knows what registers are used by called 
functions. By allocating different registers 
to the current function, saving registers 
across function calls becomes unneces- 



Recursion creates 
cycles in the program 
call graph and forces 
register saving across 
some calls. 


sary. For most programs, not enough 
registers are available to allocate all vari¬ 
ables, and only functions near the bottom 
of the call graph have local variables per¬ 
manently allocated to registers. 

Our algorithm is based on the following 
observations: 

(1) We can allocate the variables of two 
functions that cannot be active at the same 
time to the same register without creating 
a need for register saving. This property 
exists between “parallel nodes” in the pro¬ 
gram call graph and allows simple packing 
of a lot of variables in a limited number of 
registers. This technique has been used in 
Wall’s interprocedural register allocator 14 
and by others to pack the variables of 
nested functions in a single stack frame. 

(2) The call graph of most programs is 
wider at the bottom than at the top. 
Because of the first observation, this 
means that, on average, we can pack more 
variables in a fixed number of registers if 
we allocate the variables of functions in the 
bottom of the call graph—instead of the 
top—to registers. 12 

(3) Programs spend of lot of time in the 
bottom of the call graph, thus making it 
attractive to allocate these variables first. 

Recursion creates cycles in the program 
call graph and forces register saving across 
some calls. In our algorithm, each func¬ 
tion in a recursive group (a closely con¬ 
nected component of the call graph) is 
responsible for saving its local variables 
across calls inside the recursive group. 
Indirect function calls and calls to the gar¬ 
bage collector also require special 
treatment. 12 

Using bottom-up interprocedural regis¬ 
ter allocation instead of per-function allo¬ 
cation reduces the number of stack 
accesses by 73 percent on average and 
offers an average speedup of 10 percent. 
The speedup for the four largest programs 
is 7.7 percent with 75 percent of the stack 
accesses removed. More than 50 percent of 


the performance gain is due to the optimi¬ 
zation of user functions, and 85 percent of 
the remaining stack accesses after register 
allocation result from recursion. Even for 
the four largest programs, 64 percent of 
the stack accesses result from recursion 
and indirect function calls. The rest result 
from insufficient registers. 

When we compared the performance of 
interprocedural register allocation and 
hardware register windows as imple¬ 
mented in the Berkeley RISC and SPUR 
processors, we found that a register win¬ 
dow scheme with 80 registers would be 
required to eliminate the same number of 
stack references MIPS-X does with 32 
registers. 12 Hardware register windows 
have an advantage in that they can keep 
variables in registers across recursive calls 
and simplify the task of separate compila¬ 
tion. Their disadvantage is that they con¬ 
sume hardware resources (more registers 
and control logic) and are ineffective with 
small functions (common in Lisp) and 
deep, varying call depths. Register win¬ 
dows can even increase memory traffic if 
the entire window, including both used 
and unused registers, is saved and restored 
on register file overflows and underflows. 
Interprocedural register allocation does 
not have this problem since only live 
registers are saved. 

The bottom line 

Table 2 gives the execution times in mil¬ 
liseconds for the Gabriel benchmarks—a 
set of programs that tests the speed of var¬ 
ious aspects of Lisp systems. 9 The first 
two columns show the results for MIPS- 
X with and without runtime type checking. 
The times are for standard PSL without 
any optimizations added. They include the 
cost of cache misses in the on-chip instruc¬ 
tion cache and in a 64-kilobyte off-chip 
combined instruction and data cache. The 
off-chip cache is direct mapped with 
blocks of four words and a 15-cycle miss 
penalty. Type checking on MIPS-X is 
done in software as described in the sub¬ 
section “Optimizing calls to the runtime 
system,” but otherwise the data assumes 
none of the optimizations described in this 
article. 

Columns 3,4, and 5 give the results for 
three other architectures. The results for 
the VAX-11/780 are from Gabriel’s 
book. 9 The results for the Symbolics 3650 
are the latest published numbers. 15 We 
have adjusted the results for SPUR * 1 2 3 for a 
100-nanosecond cycle time instead of the 
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original 150 nanoseconds by multiplying 
by 0.67. The difference in cycle time 
between SPUR and MIPS-X (100 nanose¬ 
conds versus 50 nanoseconds) is due to a 
combination of reasons: SPUR has a more 
complicated instruction set, tagging hard¬ 
ware, a different on-chip cache organiza¬ 
tion, register windows, and possibly a less 
ambitious circuit design. 

The last three columns give the ratio of 
the execution time of VAX-11 /780, 3650, 
and SPUR to the execution time of MIPS- 
X. For SPUR and the 3650 we used the 
MIPS-X times with runtime checking. The 
numbers in Table 2 can be slightly 
influenced by differences between Lisp 
dialects: the MIPS-X and VAX numbers 
are for PSL, the SPUR numbers are for 
Common Lisp, and the Symbolics is run¬ 
ning Zetalisp. 

MIPS-X executes Lisp programs about 
15 times as fast as the VAX-11/780 and 
almost five times as fast as the Symbolics 
3650. Surprisingly, MIPS-X is about 1.5 
times as fast as SPUR. However, in all 
these cases, the performance difference 
varies significantly across the benchmarks. 

We found it interesting to trace the rea¬ 
sons for the performance difference 
between MIPS-X and SPUR. Both MIPS- 
X and SPUR are RISC processors, but 
they differ in that SPUR has hardware 
support for tag handling and type check¬ 
ing on lists, and it uses register windows to 


reduce the cost of register saving and 
restoring. The SPUR hardware for tag 
handling would eliminate about 20 percent 
of the cycles on MIPS-X, but the register 
windows do not really pay off for the 
Gabriel benchmarks and their average 
effect is neutral. The reason is that some 
of the benchmarks have a very deep call- 
depth and the large number of register file 
overflows actually slows down some pro¬ 
grams (for example, div-rec). The two 
architectural differences and the differ¬ 
ence in cycle time explain the performance 
difference. SPUR will perform better on 
more realistic programs because the regis¬ 
ter windows will be more effective, but 
even then the architectural features of 
SPUR will probably not compensate for 
the difference in cycle time with MIPS-X. 

Effect of optimizations. When we apply 
all the software optimizations discussed in 
this paper to the benchmarks, we measure 
a speedup that ranges from 0 percent to 57 
percent for the individual programs; the 
average speedup is 25 percent. Most of the 
speedup results from merging cons (13 per¬ 
cent) and using a tag implementation that 
does not require tag removal (6 percent). 
Merging under compiler control has no 
effect, and interprocedural register alloca¬ 
tion together with the improved function 
call convention contributes 6 percent. 
(Interprocedural register allocation and 


function merging are not very effective 
because the benchmarks are very recur¬ 
sive.) With the software optimizations, 
MIPS-X (doing full runtime checking in 
software) is about twice as fast as SPUR; 
if div-rec is excluded, the MIPS-X speed 
advantage drops to 1.6 times. The MIPS- 
X execution times in Table 3 include the 
effects of all the software optimizations 
discussed in this article. 

It is interesting that the most attractive 
areas for the optimization of PSL imple¬ 
mentation on the Cray 16 are the same as 
those discussed in this article: optimization 
of time-critical Lisp system functions and 
of register usage. Because the Gabriel 
times 16 include garbage collection time, it 
is hard to make a performance compari¬ 
son of MIPS-X and Cray. Unoptimized 
Cray numbers 9 indicate that the unop¬ 
timized MIPS-X implementation is about 
35 percent faster than the unoptimized 
Cray implementation. The Cray 
optimizations 16 result in a speedup of a 
factor of 3.5 (based on the real time of six 
Gabriel benchmarks). Based on this num¬ 
ber, we estimate that optimized MIPS-X 
PSL is about 1.7 times slower than 
optimized Cray PSL running on the 
X-MP. 

O ur measurements indicate that 
function calling, tag handling, 
and accessing local variables on 


Table 2. Execution times in milliseconds for the Gabriel benchmarks. 
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Ratios 



MIPS-X 

Without With 
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VAX 

3650 

SPUR 

VAX/ 
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tak 

46 

72 
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80 
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1.1 

stak 
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482 

5270 

4810 

547 

13.3 

10.0 

1.1 

ctak 

453 
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— 
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— 
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31840 
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Table 3. Execution times in milliseconds for the Gabriel benchmarks, with software optimizations for MIPS-X. 



Times in milliseconds 




Ratios 


Without 

checking 

MIPS-X 

With 
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3650 

SPUR 
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MIPS-X 
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tak 

45 

72 

450 
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2.8 

browse 
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Figure 7. Summary of speedup of the software optimizations. 


the stack account for more than 60 percent 
of the execution time of Lisp programs. 
We evaluated optimizations of these time- 
critical operations and found that software 
optimization yields results nearly as good 
as special-purpose hardware support. A 
better software implementation of the tags 
results in a speedup of 6 percent. Compare 
this with hardware support, which can 
eliminate between 9 percent and 22 percent 
of the cycles, depending on how much type 
checking is done at runtime. A simple 


interprocedural register allocator gives a 
speedup of 10 percent and eliminates 70 
percent of the stack accesses; hardware 
register windows would need twice the 
number of registers to eliminate the same 
number of stack accesses. Figure 7 sum¬ 
marizes the effect of the software optimi¬ 
zation on our 10 test programs. The total 
speedup is 35 percent. 

With hardware changes, one often pays 
for the additional feature with longer cycle 
time or extra chip area, even if the feature 


is not used. Software optimizations do not 
have this drawback, but they do reduce the 
flexibility of the programming environ¬ 
ment. For example, functions have to be 
compiled together to obtain the full bene¬ 
fit of some of these optimizations. The 
results for the Gabriel benchmarks show 
that a fast streamlined processor like 
MIPS-X outperforms special-purpose 
Lisp machines, even without these optimi¬ 
zations. 

More exploration is needed in several 
areas. Our measurements indicate that 
moving type checking from runtime to 
compiletime can give a speedup of as much 
as 20 percent. What role type deduction or 
variable declarations will play in reducing 
the amount of runtime type checking 
remains an open question. The simple 
interprocedural register allocation algo¬ 
rithm performs very well, but more work 
is needed to make the algorithm more 
robust and improve its performance, pos¬ 
sibly by using dynamic profiling informa¬ 
tion as Wall does. 14 

Our study of function integration was 
limited to the MIPS-X on-chip instruction 
cache. How would the merging strategies 
change with larger caches? Examining 
larger programs is important not only to 
determine how well these results carry 
over, but more importantly, to understand 
the effects of system-level issues such as 
memory management and garbage col¬ 
lection. □ 
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Reducing the Branch Penalty 
in Pipelined Processors 

David J. Lilja 

University of Illinois at Urbana-Champaign 


P ipelining improves computer per¬ 
formance by overlapping the exe¬ 
cution of several different 
instructions. If no interactions exist 
between instructions in the pipeline, then 
several instructions can be in different 
stages of execution simultaneously. 

However, dependencies between 
instructions—particularly branch 
instructions—prevent the processor from 
realizing its maximum performance. In a 
pipeline with sequential prefetching, for 
example, the processor must flush instruc¬ 
tions executing in the pipeline after a suc¬ 
cessful branch (since they were incorrectly 
prefetched and loaded) and fetch instruc¬ 
tions from the new path. This flushing and 
refilling reduces processor performance. 

This article develops a probabilistic 
model to quantify the performance effects 
of the branch penalty in a typical pipeline. 
The branch penalty is analyzed as a func¬ 
tion of the relative number of branch 
instructions executed and the probability 
that a branch is taken. The resulting model 
shows the fraction of maximum perfor¬ 
mance achievable under the given condi¬ 
tions. Techniques to reduce the branch 
penalty include static and dynamic branch 
prediction, the branch target buffer, the 
delayed branch, branch bypassing and 
multiple prefetching, branch folding, reso- 
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Branch dependencies 
between instructions 
penalize pipelined 
processors. Several 
simple techniques can 
restore some of the 
lost performance. 


lution of the branch decision early in the 
pipeline, using multiple independent 
instruction streams in a shared pipeline, 
and the Prepare-to-branch instruction. 

Branch types 

A branch instruction requires two pieces 
of information that the processor must 
determine before executing the instruc¬ 
tion: whether the branch is to be taken and 
the branch target address. The three basic 
types of branches in a traditional proces¬ 
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sor are unconditional, conditional (such as 
decisions), and loop control. (Loop con¬ 
trol branches are often special cases of 
conditional branches optimized for the 
regularity of loop structures.) The three 
methods used to determine the branch tar¬ 
get address are absolute address, com¬ 
puted address, and indirect address. 

An unconditional branch always alters 
the sequential program flow. The target 
address is part of the instruction itself and 
is known when the program is compiled or 
loaded. Consequently, the processor can 
treat an unconditional branch like a 
sequential program flow, except that the 
program counter is loaded with a new 
value rather than being incremented by 
one. Unconditional branches jump 
around data blocks, jump to the start of a 
program, branch to a subroutine, jump 
around the else block of an if-then-else 
construct, etc. 

In a conditional branch, the processor 
must make some decision before it can 
determine the correct execution path. The 
decision usually derives from some condi¬ 
tion code (such as a binary test on the result 
of a previous operation) and results in 
selecting either the instruction at the 
branch target address or the next sequen¬ 
tial instruction. The target address typi¬ 
cally is known at compile time. An 
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Figure 1. An example of a processor pipeline. 



i + 2 (Branch to j) 
/ + 3 


y + i 


Figure 2. An example of an instruction 
stream. 


example of a conditional branch is the if- 
then construct. 

The branch in a loop-control statement 
is usually taken and the target address is 
known when the program is compiled or 
loaded. The branch usually leads back to 
the top of the loop and is executed a fixed 
or data-dependent number of times. The 
number of iterations of the loop may 
depend on the size of a data structure (such 
as a for loop indexing through all of the 
values of an array) or the value of some 
data element (such as a while loop iterat¬ 
ing through a series of calculations until 
some error parameter reduces to an 
acceptable level). A loop-control branch 
may be a type of conditional branch or a 
special hardware instruction. 

The processor must determine the 
branch target address before executing any 


of these branch types. Some branch 
instructions provide the absolute address 
of the target instruction. Thus, fetching 
the next instruction requires no computa¬ 
tion or additional memory accesses. 

A slightly more complicated method 
computes the branch target address. An 
example of a computed target address is a 
hardware implementation of a case state¬ 
ment where control can pass to any of 
several different addresses. A more com¬ 
mon example is the register-relative 
branch. In this case, an offset added to the 
contents of the given register produces the 
branch target address. The register is fre¬ 
quently the program counter, making the 
branch “program counter-relative.” 
Relocatable object code uses this method. 

The last method of determining the tar¬ 
get address uses an indirect pointer. The 
processor uses the contents of a register as 
the address of a location in memory that 
contains the desired target address. A com¬ 
mon example is the Return-from- 
subroutine instruction, in which the 
processor does not know the target address 
at compile time but can find it on the 
return address stack before executing the 
instruction. This method uses the stack 
pointer for an indirect memory access to 
obtain the branch target address. 

Branch penalty 

To analyze the effects of these branch 
instructions on the performance of a pipe¬ 
lined processor, consider the pipeline in 
Figure 1. The first stage of the pipeline 
fetches the next instruction from memory. 
The next stage decodes the instruction, and 
the third stage generates the addresses of 
the required operands (assuming that at 
least one operand is in memory). The 
fourth stage fetches the operands. The last 
two stages perform the actual execution 


and store the results. If the instruction is 
a conditional branch, the resolution of the 
branch decision occurs in the Execute seg¬ 
ment of the pipe. 

Figure 2 shows a code fragment to be 
executed in this pipeline. Instructions /, 
f + 1, and i + 2 execute sequentially. 
Instruction / + 2 is a branch instruction 
that can either jump to instruction j if the 
branch is taken or fall through to instruc¬ 
tion i + 3 if the branch fails. 

Figure 3 shows the flow of this fragment 
through the pipeline. Instruction i enters 
the pipeline during cycle 1. The other seg¬ 
ments of the pipeline are empty and the 
processor produces no results for the first 
five cycles. This unproductive time is 
called the start-up latency. The first 
instruction completes at the end of cycle 6 
and subsequent instructions complete 
every cycle. Thus, the maximum through¬ 
put of the pipeline is one instruction per 
cycle. 

During cycle 7, the branch instruction, 
i + 2, enters segment 5. The segment exe¬ 
cutes the instruction and resolves the 
branch decision at the end of the cycle. 
Consequently, assuming the branch deci¬ 
sion is taken, the processor fetches instruc¬ 
tion./' during cycle 8 and flushes from the 
pipeline the instructions ahead of j (/ + 3 
to / +6). Thus, no instructions complete 
during cycles 9 through 12. These wasted 
cycles constitute the branch penalty. 

The penalty may be greater in proces¬ 
sors using a cache. With a forward branch, 
the cache typically does not contain the 
branch target instruction, increasing the 
penalty due to the subsequent cache miss. 
Loop instructions, on the other hand, typi¬ 
cally branch backwards by several instruc¬ 
tions, and a loop typically executes several 
times. Thus, the cache normally contains 
the branch target and the penalty consists 
only of the time taken to drain and refill 
the pipe. In the interest of simplicity, the 
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following discussion ignores cache effects. 
The discussion of the branch table buffer 
extends the model to include the effects of 
cache misses. 

Performance effect 
of the branch penalty 

The branch penalty described above 
affects processor performance whenever 
a branch is taken. That is, performance 
fails to reach its maximum value of one 
instruction per cycle whenever a nonse¬ 
quential branch is taken in the program. 

Each branch has two possible outcomes: 
taken or not taken. If the branch is taken, 
execution continues at the branch target 
address and incurs the branch penalty. If 
it is not taken, execution continues with 
the next sequential instruction and there is 
no penalty. For simplicity, assume that the 
branch target address is available when the 
branch is resolved. Other than the branch 
itself, assume the pipeline contains no 
dependencies, so each instruction 
advances one stage in the pipeline for each 
cycle. Also, the pipeline contains only one 
unresolved branch during any cycle. 
Assume the following parameters: 

Pb = the probability that a particu¬ 
lar instruction is a branch 

p, = the probability that a branch 
is taken 

b = the branch penalty (that is, the 
number of cycles wasted when 
a branch is taken) 

T ave = the average number of cycles 
required per instruction 

After the start-up latency, a nonbranch 
instruction completes every cycle. Thus, 
each nonbranch instruction requires one 
cycle to complete. For a branch instruc¬ 
tion, there are two cases to consider. If the 
branch is not taken, the time to execute the 
instruction is one cycle. If the branch is 
taken, however, execution time is one cycle 
plus b cycles due to the branch penalty. 
The average number of cycles per instruc¬ 
tion is then 

T mt = (l-p b )(l) + p b \p,(l+b) 

+ (1 -A)(l)l (1) 

which reduces to 

T„ V e = 1 + bp b p, (2) 

Equation 2 shows that the average num¬ 
ber of cycles required to execute an instruc¬ 
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Figure 3. Instruction flow in the example pipeline showing the branch penalty. 


tion is one plus a fraction of b, the branch 
penalty. Let this fraction be p e , where p e 
= PbP t . For the simple pipeline model 
presented here, this fraction is determined 
by the percentage of branch instructions 
executed and the probability that the 
branch is taken. Think of it as the effective 
fraction of the branch penalty incurred by 
the instructions. 

Maximum performance occurs when 
the branch penalty is zero and one instruc¬ 
tion completes every cycle. Thus, with no 
branch penalty, the average number of 
cycles per instruction is one. Define F b as 
the number of cycles required to execute 
an instruction in the maximum perfor¬ 
mance case (that is, one cycle) divided by 
the average number of cycles required to 
execute an instruction when the branch 
penalty is included. Then 



Figure 4 uses F b , interpreted as the frac¬ 
tion of maximum performance realized by 
the pipeline due to the effects of the branch 
penalty, as the vertical axis. The horizon¬ 
tal axis is the effective probability that an 
instruction is a taken branch (p e ). The 
curves represent values of b ranging from 
one to six. 


Lee and Smith analyzed branching 
behavior from the traces of 26 programs 
totaling more than 94 million instruc¬ 
tions. 1 The programs consisted of a mix 
of compiler, business, scientific, and oper¬ 
ating system programs run on an IBM Sys¬ 
tem/370; a typical mix of educational 
programs run on a PDP-11-70; and several 
scientific programs run on a CDC 6400. 
These programs showed the average Pb to 
be approximately 0.1 to 0.3 and the aver¬ 
age p, to be approximately 0.6 to 0.7. 
That is, about 10 percent to 30 percent of 
the instructions executed in a typical pro¬ 
gram are branch instructions, of which the 
branch is taken about 60 percent to 70 per¬ 
cent of the time. Thus, the average effec¬ 
tive probability that an instruction is a 
taken branch is 0.06 to 0.21. Referring to 
Figure 4, iip b = 0.2, p, = 0.65, and b = 
4, for example, then p e = 0.13 and the 
branch instructions cause the pipeline to 
execute at about 66 percent of its maxi- 

Note that the range of F b is 0 < F b < 1. 
The upper bound (one) occurs whenever 
any of the terms in the denominator of 
Equation 3 are zero. That is, the processor 
executes at the maximum rate of one 
instruction per cycle when the branch pen¬ 
alty is zero, when there are no branch 
instructions, or when the branches are 
never taken. The processor approaches the 
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Figure 4. Fraction of maximum performance as a function of the effective proba¬ 
bility and the branch penalty b. 


lower bound of zero asymptotically when 
there is a nonzero probability that a branch 
exists and is taken and the branch penalty 
b becomes very large. Between these limits, 
processor performance degrades rapidly 
for even small values of b and p e . These 
curves demonstrate the significant effect 
branches can have on the performance of 
a pipelined processor. 

Branch prediction 

Branch prediction reduces performance 
degradation due to branch instructions. A 
pipeline with branch prediction uses some 
additional logic to guess the outcome of a 
branch decision before it is determined. 
The pipeline then begins prefetching the 
instruction stream from the predicted 
path. (Note that the predicted path may be 
the normal sequential path.) Thus, a cor¬ 
rect prediction eliminates wasted cycles 
due to the branch penalty. 

If the branch is predicted to be taken, 
the branch target address also must be 
predicted. The branch target address may 
be explicitly encoded into the instruction 
or it may be predicted, for example, to be 
the same target address as the last execu¬ 


tion of the instruction. 

The processor may predict the branch 
path either statically or dynamically. In the 
static case, the processor makes a 
presumptive decision as to whether the 
branch is likely to be taken. Whenever the 
instruction executes, the processor 
prefetches from the same predicted path. 
In the dynamic case, the hardware main¬ 
tains some past information on the branch 
instruction being executed. The processor 
then uses this information to predict the 
branch decision according to some predic¬ 
tion algorithm. 

Static branch-prediction mechanisms. 

The simplest form of static prediction 
predicts that all branches are always taken 
or never taken. A typical pipelined com¬ 
puter fetches instructions sequentially, 
even after a branch has been decoded. This 
sequential fetching is equivalent to stati¬ 
cally predicting that branches are never 
taken. Alternatively, we could design a 
pipeline to begin fetching from the branch 
target path whenever it encounters a 
branch instruction. This method is equiva¬ 
lent to predicting that branches are always 
taken. Studies analyzing program 
behavior have shown that branches are 


taken more than 50 percent of the time, 1 
so if the cost of prefetching from either 
path is the same, then always prefetching 
from the branch target address should give 
better performance than always prefetch¬ 
ing from the sequential path. 

Another form of static prediction is 
based on the op-code of the branch 
instruction. The hardware assumes that 
the branch will be taken for certain branch 
op-codes and not for others. When the 
instruction is decoded, the op-code 
implicitly determines the branch- 
prediction decision. This mechanism 
allows prediction accuracies of greater 
than 75 percent. 

A slightly more complicated form of 
static prediction uses a likely/not-likely bit 
within the instruction. The hardware 
prefetches the branch target instruction if 
the bit is set; otherwise, it prefetches the 
next sequential instruction. The compiler 
determines the setting depending on the 
apparent use of the branch within the pro¬ 
gram, or using some intelligent heuristic 
algorithm. For example, it would set loop- 
control branches to likely and branches 
that exit a loop to not likely. Accuracy 
depends on the compiler’s ability to pre¬ 
dict the branch decision. Using a set of 
benchmark programs, Ditzel and McLel- 
lan reported prediction accuracies of 74 
percent to 94 percent for the AT&T CRISP 
processor, which uses this prediction 
mechanism. 2 

Another method of determining the set¬ 
ting for the likely bit involves tracing the 
execution of a program using several 
different data sets and recording the out¬ 
comes of all of the branch decisions. The 
likely bit is then set to the outcome that 
occurred most often for that particular 
branch instruction. By simulating this 
technique, McFarling and Hennessy 3 
found a correct prediction rate of 85 per¬ 
cent averaged over several benchmark pro- 
grams. Furthermore, the correct 
prediction rate fell only slightly when sig¬ 
nificantly different input data sets were 
used. 

Dynamic branch-prediction mechan¬ 
isms. In dynamic prediction techniques, 
the processor uses history information 
about branch instructions that have 
executed to predict the outcome of the 
branch the next time it executes. For exam¬ 
ple, the processor can maintain a small 
table for recently executed branch instruc¬ 
tions with several bits in each entry. It can 
access the table associatively like a data 
cache, or by using the low-order bits of the 
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branch instruction’s address. The proces¬ 
sor then uses the bits to make a prediction 
decision with some heuristic algorithm. 
The hardware costs of this mechanism will 
be influenced by the number of entries in 
the history table, the number of history 
bits maintained, the set-associativity of the 
table, and other such cache-related issues. 

Lee and Smith 1 analyzed several differ¬ 
ent schemes for predicting the branch out¬ 
come using the stored history bits. Using 
a single history bit yielded prediction 
accuracies ranging from about 80 percent 
to 96 percent on the previous mix of 
instruction traces. Accuracy increased as 
the number of history bits increased. Using 
five bits resulted in prediction accuracies 
ranging from 84 percent to 98 percent. 
Another study resulted in dynamic predic¬ 
tion accuracies of 83 percent averaged over 
three smaller benchmark programs. 3 

Consider the following example of a 
prediction algorithm based on history bits. 
A finite-state machine implements this 
algorithm with two bits in each table entry. 
If the last two branches for the given 
instruction have taken the same path, the 
prediction is to take that path again. If the 
prediction is wrong, it remains the same 
the next time the instruction executes. If 
the prediction is wrong again, however, 
the prediction will be to select the opposite 
path the next time. Thus, the algorithm 
requires two consecutive wrong predic¬ 
tions to change the predicted path; if a 
branch executes an unusual direction once, 
the prediction will be wrong only once. 
This type of branching behavior is com¬ 
mon for loops executing within another 
loop. 

The S-l computer uses a dynamic 
prediction technique. The processor has a 
jump bit and a wrong bit associated with 
each branch instruction. 1 The jump bit is 
set to indicate that the branch is predicted 
to be taken, while the wrong bit is set to 
indicate that the last prediction was wrong. 
Two consecutive wrong predictions toggle 
the jump bit. This mechanism is similar to 
the one described above. The Mitsubishi 
M32 microprocessor, developed as part of 
the Japanese TRON project, 4 also uses a 
dynamic prediction mechanism. 

Performance effects 
of branch prediction 

A simplified model using the pipelined 
processor in Figure 1 as an example pro¬ 
vides a feel for how branch prediction may 
reduce the performance degradation of 


Table 1. Branch penalties (in cycles) 
for predicted and actual outcomes. 


Actual 

Prediction Not taken Taken 

Not taken 0 b 

Taken c d 


branch instructions. Table 1 shows the 
four combinations of predicted and actual 
branch outcomes along with the perfor¬ 
mance penalty of each outcome. The 
actual performance of the processor is 
determined as follows. 

If the prediction is that the branch will 
not be taken, then the first row of the table 
applies and the average number of cycles 
required to execute the instructions is the 
same as in Equation 2. However, if the 
prediction is that the branch will be taken, 
then from the second row of the table, 

Tave = 1 + cp b (l —p t ) + dp b p, (4) 

An incorrect prediction calls for c addi¬ 
tional cycles, and a correct prediction, d 
additional cycles. 

Assume that the penalty of a correctly 
predicted taken branch in Figure 1 is zero 
(d - 0). Also, assume that the penalty for 
an incorrect prediction is the same regard¬ 
less of whether the actual outcome is taken 
or not taken (that is, c = ft). Under these 
circumstances, the average number of 
cycles required to execute an instruction is 

T a ve = 1 + bp b p w (5) 

where p w is the probability of a wrong 
prediction. Thus, the b branch penalty 
cycles are wasted only when the prediction 
is wrong. 

This performance equation is essentially 
the same as the one developed for the 
branch penalty. Thus, we can use Figure 
4 to determine the fraction of maximum 
performance realized by using p e = p b p w . 
For example, if 20 percent of the instruc¬ 
tions are branches and the prediction algo¬ 
rithm is correct 80 percent of the time, then 
p e = 0.04. Using a branch penalty of ft = 
4, we find from Figure 4 that the proces¬ 
sor will operate at about 86 percent of its 
maximum value. 

By predicting the branch outcomes with 
an accuracy better than the probability of 
a branch being taken (p„ < p,), a proces¬ 
sor using branch prediction can outper¬ 


form one without it. While this model is a 
simplification, it helps explain the effec¬ 
tiveness of branch prediction. However, 
the potential increase in processor perfor¬ 
mance must be balanced against the actual 
cost of the extra hardware, the software 
costs, and the real performance cost of an 
incorrect prediction. 

Branch target buffer 

In a typical pipelined processor, the 
processor consumes new instructions 
faster than the main memory can deliver 
them. Consequently, instructions are 
prefetched from the sequential instruction 
stream into a prefetch buffer. When the 
processor needs the next instruction, it is 
available from the prefetch buffer without 
delay. When a nonsequential branch 
occurs, however, the required instruction 
most likely is not in the prefetch buffer. To 
alleviate this problem, we can use a branch 
target buffer. 

The BTB is a special, selective cache 
memory associated with the instruction- 
fetch portion of the pipeline. Each entry 
in the BTB consists of the address of a 
branch instruction that has already 
executed and the target instruction itself. 
The BTB may also store the next few 
instructions after the branch target 
instruction. 

When the pipeline decodes a branch 
instruction, it associatively searches the 
BTB for the address of that instruction. If 
it is in the BTB, the instruction is supplied 
directly to the pipeline and prefetching 
begins from the new path. If the instruc¬ 
tion is not in the BTB, however, the pipe¬ 
line is stalled while it fetches the new 
instruction stream. The processor then 
selects an entry in the BTB for replacement 
and stores the new target instruction in the 
BTB. 

The BTB also can be called a loop 
buffer. In many cases, a loop may be small 
enough to completely fit within the BTB. 
Thus, the pipeline can execute the loop 
directly out of this special-purpose instruc¬ 
tion cache. Loop buffers have been suc¬ 
cessfully implemented in the Cray-1, IBM 
System/360 Model 91, and Mitsubishi 
M32. 4 

The Advanced Micro Devices Am29000 
microprocessor also incorporates a BTB to 
increase performance due to repeated 
branches. 5 In this implementation, a 
512-byte cache is divided into 128 32-bit 
words (each instruction uses one word). 
Two-way set-associative mapping is used, 
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and a random-replacement strategy 
resolves collisions between entries that 
map to the same location. Each entry in 
this BTB consists of four sequential 
instruction words for a total of 32 unique 
branch targets in the entire BTB. When a 
nonsequential instruction fetch occurs, the 
BTB is searched simultaneously with the 
address translation in the memory 
management unit. If the target instruction 
is in the BTB, it is passed to the pipeline 
along with the next three instructions. The 
instruction prefetch unit then begins 
prefetching from this new path. 

We can extend the performance model 
developed for the branch penalty to 
include the effects of adding a BTB to the 
pipeline model in Figure 1. Assume that 
the sequential program path is always 
being prefetched and that no extra cycles 
are required to fetch the branch target 
instruction from the BTB on a hit. Let b ’ 
be the number of branch penalty cycles 
and c be the number of cycles required to 
fetch the branch target instruction on a 
BTB miss. Then, the average number of 
cycles required to execute an instruction is 

T ave = 1 + (b' + cp m )p b p, (6) 

where p m is the probability of a BTB miss. 

In this model, the effective probability 
is p e = p b p„ while the effective branch 
penalty is the normal branch penalty, b ', 
plus a fraction of the number of cycles 
required for a BTB miss. In terms of Equa¬ 
tion 3 and Figure 4 , b = b' + cp m . For 
example, in a processor with 20 percent 
branch instructions, of which 65 percent 
are taken, p e = 0.13. With a BTB miss 
ratio of 25 percent, a branch penalty of b' 
= 4, and c = 2 cycles required to service 
a miss, the effective branch penalty is b = 
4.5 cycles. Interpolating with Figure 4, or 
using Equation 3 directly, the processor 
will realize approximately 63 percent of its 
maximum possible performance. 

To determine the effectiveness of the 
BTB, Lee and Smith examined the hit 
ratios for several different workloads. 1 
(The hit ratio is the probability that the 
desired instruction will be in the BTB when 
fetched, which is 1 —p m .) Using a two- 
way set-associative BTB with 16 entries 
and a least-recently-used replacement 
strategy, the hit ratio was approximately 
27 percent. When the BTB size increased 
to 64 entries, the hit ratio increased to 
approximately 47 percent. A BTB size of 
256 entries resulted in a hit ratio of 72 per¬ 
cent. Using a direct-mapped scheme and 
a different workload mix, McFarling and 



The compiler for a 
processor with 
delayed branches 
detects dependencies 
in the instruction 
stream. 


Hennessy found average hit ratios of 47 
percent, 83 percent, and 93 percent for a 
BTB with 16, 64, and 256 entries, respec¬ 
tively. 3 They attributed their higher 
results to different workload charac¬ 
teristics. 


Delayed branch 

In an architecture using a delayed 
branch, some number of instructions after 
the branch execute regardless of whether 
the branch is taken. In particular, let 
instruction / be a branch to instruction j. 
A processor with a branch delay of b will 
execute the instructions in the sequence i, 
i + 1, ...,/ + b, j, ... if the branch is 
taken. If the branch is not taken, instruc¬ 
tion i+b is followed by / + b + 1. Thus, 
the b instructions after the branch always 
execute. 

The compiler for a processor with 
delayed branches detects dependencies in 
the instruction stream and rearranges the 
code to insert useful instructions in the 
delay slots. For example, the compiler can 
determine that the program dependencies 
allow a few of the instructions preceding 
the branch to be moved into the delay slots 
after the branch. Then, when the branch 
executes, these instructions will always 
execute, whether the branch is taken or 
not. The effect is the same as if the instruc¬ 
tions executed in their original order, 
except that the branch penalty decreases. 
Other, more complicated, code rearrange¬ 
ment schemes are also possible. In many 
cases, however, some or all of the b 
instructions after the branch must be filled 
with no-ops. 

Gross and Hennessy developed an algo¬ 
rithm for optimizing delayed branches in 
the compiler for the MIPS project. 6 For a 
series of small benchmark programs, this 
compiler filled the first delay location after 
a branch with a useful instruction more 


than half of the time. Subsequent delay 
locations were increasingly more difficult 
to fill. The compiler for the IBM 801 
minicomputer 7 filled the single delay slot 
in that processor with a useful instruction 
approximately 60 percent of the time. The 
Am29000 s and several other computers 
have also successfully used the delayed 
branch scheme. 

To simplify reordering the instruction 
stream, the delayed branch in the Hewlett- 
Packard Precision architecture 8 includes 
a nullification or canceling feature, allow¬ 
ing a branch instruction to dynamically 
force the next instruction after the branch 
to be a no-op, depending on the outcome 
of the branch itself. This feature is com¬ 
monly used in a loop-control branch at the 
bottom of a loop. For example, in a 
processor with a branch delay of one, the 
instruction after the branch can be a copy 
of the first instruction at the top of the 
loop. The branch target then is the second 
instruction of the loop. When the branch 
fails and the loop is exited, the instruction 
after the branch is nullified and execution 
continues sequentially. 

Hsu and Davidson have proposed an 
extension of the nullification concept using 
the idea of guarded instructions, in which 
a Boolean-valued guard expression is 
added to a Store instruction or a condi¬ 
tional branch. 9 If the guard expression 
evaluates to false, it inhibits the Store or 
branch operation, converting the instruc¬ 
tion to a no-op. 

For example, consider a Store instruc¬ 
tion that is the target of a conditional 
branch. It should execute only if the 
branch is taken. Most processors with a 
delayed branch cannot move this instruc¬ 
tion into a delay slot due the instruction’s 
dependence on the outcome of the branch. 
However, a guard expression that is a 
function of the branch condition allows 
the processor to move the Store instruction 
into a delay slot by ensuring that the Store 
will be inhibited if the branch is not taken. 

Using this technique and a decision-tree 
scheduling heuristic, Hsu and Davidson 
achieved performance speedups for the 
memory scheduler from the Unix kernel of 
1.7 to 4.6 times over a conventional pipe¬ 
lined processor. 9 In this study, the branch 
penalty was much larger than that of the 
example pipeline in Figure 1. Conse¬ 
quently, using the guarded instruction 
scheme in this pipeline would result in 
smaller speedups than those achieved by 
Hsu and Davidson. 

As before, we can modify the perfor¬ 
mance model of the branch penalty to 
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include the effects of using a delayed 
branch architecture. In a processor with b 
delay slots and without the nullification 
feature, the average number of cycles 
required to execute an instruction is 

T aw = 1 + bp„p nop (7) 

Notice that since the b delay cycles execute 
whether or not the branch is taken, the 
probability p t is not involved in this equa¬ 
tion. Instead, the equation uses the frac¬ 
tion of the b delay slots filled with no-ops, 
Pnop . If fi is the probability that delay slot 
i is filled with a useful instruction, then 


Thus, p nop shows the fraction of the delay 
slots that do no useful work and thereby 
add to the branch penalty. 

Again, the form of the equation for 
T me allows us to use Figure 4 to estimate 
the fraction of maximum performance in 
this pipeline. In this case, p e = p b p„ 0 p- 
For example, assume that a processor with 
a branch delay of four can fill the first 
delay slot with a useful instruction 60 per¬ 
cent of the time, and the second delay slot 
only 10 percent of the time. The last two 
delay slots are never used. Using these 
values for f, p nop = 0.825. With p b = 
0.2, p e = 0.165, resulting in 60 percent of 
the processor’s maximum performance 
being realized. 

In a processor with this feature, nullify¬ 
ing the instructions in the delay slots wastes 
b cycles on the branch. If the processor 
resolves the branch so the instructions can 
execute, however, the branch penalty is 
only bp nop additional cycles. Conse¬ 
quently, the average number of cycles 
required to execute an instruction is 


T ave = 1 + bp b \p nop (\-p„ u ii) 

+ Pnuu\ ( 9 ) 


The term p„ u u is the probability that the 
instructions in the delay slots are nullified. 
This probability equals the probability that 
the branch is taken, p„ if the instruction is 
of the Nullify-on-branch-taken type. 
Otherwise, p„ u n = (1 -p,). In this model, 
the effective probability is 


Pe = Pb\PnopO Pnull) + Pnull] ( 10 ) 

Since the nullification scheme allows the 
instructions in the delay slots to execute 
only when the branch is in a particular 



The processor can 
fetch both paths and 
throw away the 
incorrect one when 
the branch is resolved. 


direction, the compiler can more effec¬ 
tively put useful instructions in the delay 
slots. Consequently, it is likely that the 
fraction of delay slots filled with no-ops, 
p„ 0 p , will be smaller than in a processor 
that does not use nullification. Or, equiva¬ 
lently, we can assume that the probability 
of a useful instruction filling a delay slot 
i (fi ) will be larger than in the no¬ 
nullification case. 

For instance, in a processor with nullifi¬ 
cation and b = 4, assume that// = 0.8, f 2 
= 0.3,/j = 0.1, and f 4 = 0, which gives 
Pnop = 0.70. Assuming that nullification 
occurs when the branch is not taken, p„ utl 
= (1 ~Pt) = 0.35. The effective probabil¬ 
ity is then p e = 0.161, which, using Figure 
4, results in the processor executing at 61 
percent of its maximum performance. 
Notice that with these parameters, the per¬ 
formance of the processor with nullifica¬ 
tion is only about one percent better than 
the previous example without nullifi¬ 
cation. 


Branch bypass and 
multiple prefetch 

To eliminate the need to predict which 
path will be taken after a branch, the 
processor can fetch both paths and throw 
away the incorrect one when the branch is 
resolved. This technique is called branch 
bypassing or multiple prefetching. A pipe¬ 
line that can contain only one branch 
instruction at any given time must prefetch 
two execution paths. Similarly, a proces¬ 
sor that can contain two unresolved 
branches must prefetch four paths. Two of 
the paths are from the taken/not-taken 
choices of the first branch, while two are 
from the taken/not-taken choices of the 
second. The pipeline must prefetch all four 
paths until the branches are resolved. In 
general, if the pipeline can contain j 


unresolved branches at the same time, then 
it must prefetch 2 J execution paths. 

The performance advantage of 
prefetching all of the execution paths is 
that the processor has already fetched the 
correct path from memory when it finally 
resolves a branch. If the hardware does 
this without executing the paths, there will 
be some performance penalty as the pipe¬ 
line flushes and refills as it resolves the 
branches. However, we can design hard¬ 
ware that actually executes more than one 
of the paths, perhaps using the guarded 
execution scheme mentioned above. In 
terms of the previous performance 
models, we can reduce the branch penalty 
b to almost zero at the expense of suffi¬ 
ciently complicated hardware. 

To determine the theoretical maximum 
speedup from bypassing a number of 
branches, Riseman and Foster 10 simu¬ 
lated the performance of a hypothetical 
machine with infinite storage and an 
infinite number of functional units. Per¬ 
formance in this machine is limited only by 
data and branch dependencies. They dis¬ 
covered that performance increases 
proportional to \fj, where j levels of 
unresolved branches exist. For example, a 
processor maintaining the possible out¬ 
comes of 16 branches theoretically runs 
twice as fast as one maintaining four out¬ 
comes, which runs twice as fast as one 
maintaining only one outcome. This rela¬ 
tion seems to hold for values of j up to 32. 
Since the number of paths to be main¬ 
tained grows as 2 j , but the performance 
grows as \f j, this technique is unreasona¬ 
ble beyond very small values of j. 


Branch folding 

The AT&T CRISP processor 2 uses a 
technique called branch folding that can 
reduce the branch penalty to zero. In this 
processor, the pipeline is broken into a 
fetch-and-decode unit and an execution 
unit. The fetch-and-decode unit reads 
encoded instructions from memory and 
places the decoded instructions into a spe¬ 
cial instruction cache. Each decoded 
instruction has an associated next-address 
field that is the address of the next instruc¬ 
tion to be executed. Thus, each instruction 
can be an unconditional branch instruc¬ 
tion in addition to its normal operation. 

The fetch-and-decode unit recognizes 
when an unconditional branch instruction 
follows a nonbranch instruction and 
“folds” the branch instruction into the 
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nonbranch instruction, effectively 
eliminating the branch instruction from 
the execution pipeline. 

Conditional branch instructions main¬ 
tain an alternate next-address field along 
with the normal next-address field. When 
a folded conditional instruction executes, 
the execution unit selects one of the two 
next-address paths. The address of the 
other path proceeds down the pipeline with 
the executing instruction. When the pipe¬ 
line finally resolves the branch, it either 
throws away the alternate path address or 
flushes itself and restarts execution at the 
alternate address. 

Since no explicit branch instructions 
exist in the execution pipeline, the branch 
penalty becomes zero for unconditional 
branches. The performance for condi¬ 
tional branches is the same as that in the 
first performance model with p b replaced 
by the probability of an instruction being 
a conditional branch. The cost of this tech¬ 
nique is significantly more complicated 
hardware. 


Early branch resolution 

As shown in the performance model of 
the branch penalty, processor perfor¬ 
mance degrades by a fraction of the 
branch penalty when a branch instruction 
is taken. The fraction of maximum perfor¬ 
mance realized by the processor increases 
as the branch penalty decreases. For exam¬ 
ple, if the branch decision is resolved in the 
first stage of the pipeline in Figure 1, the 
branch penalty can be reduced to zero. No 
degradation of processor performance due 
to a taken branch exists in this case. How¬ 
ever, effectively resolving branches early 
in the pipeline may require a significant 
amount of hardware. In fact, this addi¬ 
tional hardware may increase the critical 
path delay and thus the processor’s cycle 
time, potentially reducing overall per¬ 
formance. 

In the Tandem VLX computer sys¬ 
tem," the processor uses extra logic to 
test the branch condition before the 
branch executes. By anticipating the 
branch direction, the processor can fetch 
instructions from the target address into 
the cache and immediately load the new 
instruction stream into the pipeline. Of 
course, the processor may not always be 
able to determine the branch condition 
early enough, in which case the pipeline 
must wait. The increased performance in 
executing branch instructions offsets the 
cost of the extra logic. 


Multiple independent 
instruction streams 
in a shared pipeline 

Most high-performance processors are 
multiprogrammed, with several indepen¬ 
dent processes sharing execution time on 
a single processor. We can eliminate 
dependencies within the pipeline by inter¬ 
leaving the execution of these processes so 
each stage of the pipeline has a different 
process. 

For example, an n -stage pipeline exe¬ 
cutes n different processes simultaneously. 
Each stage of the pipeline executes an 
instruction from one of the n different pro¬ 
cesses. Since each process is independent, 
no branch dependencies exist between 
instructions in the pipeline. Consequently, 
execution of a branch instruction carries 
no performance penalty. Of course, each 
process runs at a fraction of 1 /n times its 
maximum possible performance. The 
advantage is that the pipeline is completely 
used, thereby increasing overall system 
performance (as measured by the number 
of instructions executed per unit of time). 

Shar and Davidson 12 discussed this 
concept of multistreaming, and it was 
incorporated into the design of the Denel- 
cor HEP computer system. 13 The HEP 
system broke programs into several 
independent, cooperating processes. Each 
process experienced a performance degra¬ 
dation of 1/n, but the entire distributed 
program ran at the maximum perfor¬ 
mance allowed by the pipeline. 


Prepare-to-branch 

instruction 

The techniques discussed so far 
implicitly assume that the branch target 
address is immediately available or that it 
can be calculated in parallel with the reso¬ 
lution of the branch decision. Thus, deter¬ 
mining the target address was assumed to 
have no effect on pipeline performance. 
However, the instruction-fetch logic may 
need some advance warning about a 
branch to begin prefetching from the 
appropriate instruction stream. For exam¬ 
ple, the Texas Instruments ASC 
computer 14 uses the Prepare-to-branch 
instruction to give the control hardware 
advance warning that a branch instruction 
is going to execute. This warning passes the 
branch target address to the control unit 
so that the unit can begin instruction 
prefetching from that address. The useful¬ 


ness of the Prepare-to-branch instruction 
depends on the ability of the compiler or 
programmer to insert the instruction at the 
appropriate point in the instruction 
stream. 

E xtensive use of pipelining has 
increased the parallelism, and 
thus the performance, of high¬ 
speed processors. The first model in this 
article showed how branch dependencies 
between instructions in the segments of a 
pipelined processor reduce processor per¬ 
formance. The different techniques 
presented can reduce the performance 
effects of branch instruction execution. 
While the performance models developed 
for these techniques are somewhat simpli¬ 
fied, they provide a useful method of com¬ 
paring the performance effects of various 
architectural alternatives. 

Not all of the techniques will be useful 
for every processor. The choice of which 
techniques to use depends on the perfor¬ 
mance requirements and cost constraints 
of the particular processor design. The 
simplicity of some of the techniques, how¬ 
ever, suggests that almost any pipelined 
processor could benefit from one of the 
methods. □ 


Acknowledgments 

I wish to thank Edward S. Davidson for his 
helpful comments on an early version of this 
article. In addition, the thoughtful comments 
provided by the reviewers have significantly 
enhanced the quality of this presentation. 

This paper was written while I was supported 
by the Center for Supercomputing Research and 
Development under the following grants: 
National Science Foundation MIP-8410110, US 
Department of Energy DE-FG02-85ER25001, 
and the IBM Donation. 


References 

1. J.K.F. Lee and A.J. Smith, “Branch- 
Prediction Strategies and Branch Target 
Buffer Design,” Computer, Jan. 1984, pp. 
6-22. 

2. D.R. Ditzel and H.R. McLellan, “Branch 
Folding in the CRISP Microprocessor: 
Reducing Branch Delay to Zero,” Proc. 
14th Ann. Symp. Computer Architecture, 
1987, pp. 2-9. 

3. S. McFarlingand J. Hennessy, “Reducing 
the Cost of Branches,” Proc. 13th Ann. 
Symp. Computer Architecture, 1986, pp. 
396-403. 

4. T. Yoshida and T. Enomoto, “The Mit¬ 
subishi VLSI CPU in the TRON Project,” 
IEEE Micro, Apr. 1987, p. 24. 


54 


COMPUTER 









5. M. Johnson, Am29000 User’s Manual, Advanced Micro Devices, 
Sunnyvale, Calif., 1987. 

6. T.R. Gross and J.L. Hennessy, “Optimizing Delayed Branches,” 
Proc. IEEE Micro-15, Oct. 1982, pp. 114-120. 

7. G. Radin, “The 801 Minicomputer,” IBMJ. Research and Devel¬ 
opment, May 1983, pp. 237-246. 

8. M.J. Mahon etal., “Hewlett-Packard Precision Architecture: The 
Processor,” Hewlett-Packard J., Aug. 1986, pp. 4-21. 

9. P.Y.T. Hsu and E.S. Davidson, “Highly Concurrent Scalar Process¬ 
ing,” Proc. 13th Ann. Symp. Computer Architecture, 1986, pp. 
386-395. 

10. E.M. Riseman and C.C. Foster, “The Inhibition of Potential Par¬ 
allelism by Conditional Jumps,” IEEE Trans. Computers, Dec. 1972, 
pp. 1,405-1,411. 

11. Anon., “Tandem Makes a Good Thing Better,” Electronics, Apr. 
14, 1986, pp. 34-38. 

12. L.E. Shar and E.S. Davidson, “A Multiminiprocessor System Imple¬ 
mented Through Pipelining,” Computer, Feb. 1974, pp. 42-51. 

13. B.J. Smith, “Architecture and Applications of the HEP Multipro¬ 
cessor Computer System,” Real-Time Signal Processing IV, Proc. 
SPIE, 1981, pp. 241-248. Reprinted in Supercomputers: Design and 
Applications, Kai Hwang, ed.. Computer Society Press, Silver Spring, 
Md„ pp. 231-238. 

14. W. J. Watson, “The TIASC—A Highly Modular and Flexible Super¬ 
computer Architecture, ’ ’ Proc. AFIPS Fall Joint Computer Conf., 
Vol. 41, AFIPS Press, Montvale, N.J., Dec. 1972, pp. 221-228. 



David J. Lilja is a doctoral candidate in the Department of Electrical and 
Computer Engineering and a graduate research assistant in the Center 
for Supercomputing Research and Development at the University of 
Illinois at Urbana-Champaign. His main research interests are in com¬ 
puter architecture and parallel processing. 

Lilja received a BS in computer engineering from Iowa State Univer¬ 
sity and an MS in electrical engineering from the University of Illinois. 
He is a member of Tau Beta Pi, Eta Kappa Nu, and Phi Kappa Phi, a stu¬ 
dent member of the Computer Society, and a registered Professional 
Engineer in California. 

Readers may write to Lilja at the Center for Supercomputing Research 
and Development, University of Illinois at Urbana-Champaign, 305 Tal¬ 
bot Laboratory, 104 S. Wright St., Urbana, IL 61801-2932. 



-P/VJ 'ciV 

^—AUTOMATION 
^-TECHNOLOGIES 


Arthur D. Little’s Technology Resource Center in 
Washington, D.C., now entering its sixth year, is 
seeking individuals who have demonstrated superior 
performance in their field. We have openings for: 

• Electrical Engineers/ 

Computer Scientists 

Theoretical and practical knowledge of computer 
vision, image processing, and pattern recognition, 
with emphasis on hardware development. Some 
experience with artificial intelligence techniques, 
especially expert systems, is desirable. 

• Mechanical Engineer 

Experience in research and development of sophis¬ 
ticated materials handling or factory automation 
components and systems. State-of-the-art work will 
include development of advanced technologies to 
feed, sort and dispatch mail with high throughput 
and minimum downtime. 

• Operations Research/ 
Industrial Engineering 

Experience in system simulation, cost-benefit 
analysis of engineering projects, manufacturing 
system design and knowledge of applied statistics 
and probability are required. 

These positions require an M.S. or Ph.D. degree 
and at least 5 years of experience in research or 
advanced development. Outstanding communica¬ 
tion skills, both oral and written, are required. 
Arthur D. Little’s Technology Resource Center is 
providing long-term advanced technology planning 
and development support for the U.S. Postal Serv¬ 
ice. This includes support of a contract research 
program on new automation technologies to 
improve the efficiency of mail handling, transpor¬ 
tation and other postal services. 

As part of the Technology Resource Center, the 
successful applicants will work closely with the 
client in developing a research plan for work by in¬ 
vestigators at many institutions, monitoring progress 
and research performance and participating in on¬ 
site design reviews. There are opportunities for 
analysis and advanced development of state-of-the- 
art components and systems. These high-visibility 
positions offer opportunities for direct client con¬ 
tact, participation in high-level planning, and work 
in a stimulating, multidisciplined research environment. 
Arthur D. Little, Inc.’s compensation program pro¬ 
vides a comprehensive benefit package including 
medical/dental coverage, profit sharing, and a 
generous retirement/investment plan. 

If you are interested in exploring employment op¬ 
portunities with us, send a resume to Jeffrey D. 
Chartier, Arthur D. Little, Inc., 20 Acorn Park, 
Cambridge, MA 02140. We are an equal opportu¬ 
nity employer. 


/ti Arthur D. Little, Inc. 


July 1988 








ADVANCE ANNOUNCEMENT 


Conference on 
Software 

Maintenance-1988 (CSM ’88) 

Phoenix, Arizona, USA • October 24-27, 1988 



Sponsors: 

Computer Society of the IEEE—Technical Committee on Software Engineering 
The Institute of Electrical and Electronics Engineers. Inc. 

National Bureau of Standards (NBS) 


acm 



In Cooperation With: 

ACM. SIC.SOFT—Special Interest Croup on Software Engineering 
Software Maintenance Association (SMA) 


The conference will begin on Monday, October 24, 1988 with the following tutorial sessions: 

• Software Product Assurance—presented by Dr. Stan Siegel and Dr. William Bryan, Grumman Data Systems 

This tutorial is a management overview of software product assurance. Product assurance is a set of checks and balances interwoven into 
the software development and maintenance process to assure that a software product satisfies customer needs. These checks and 
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how applying product assurance can reduce the risks involved in developing and maintaining software systems in the real world. Here, 
"real world" means "constrained budgets, tight schedules, and software customers who change their minds." It includes disciplines 
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• Using Software Complexity Metrics in Program Maintenance-presented by Dr. Warren Harrison and Dr. Curtis Cook, SET Laboratories. Inc. 
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Tuesday, October 25,1988 will feature a keynote address, entitled “Maintenance Equals Reuse Oriented 
Software Development”, by Dr. Victor Basili, University of Maryland. The conference will proceed with the 
presentation of 52 technical papers during the following sessions and panel discussions: 
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3A. Formal Transformations and Methods-Chair: David Gustafson, 
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3B. Configuration Management-I-Chair: Bruce I. Blum, Johns 
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, 3C. Software Tools Initiative-Chair: Richard Fath, Federal Com¬ 
munications Commission 
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4B. Configuration Management-II—Chair: Ned Chapin, Califor¬ 
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5B. Configuration Management-III-Chair: Mary Ann Overman, 
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Osborne, National Bureau of Standards 

7C. Knowledge-Based Approaches to Software Maintenance-Chair: 
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ton, U.S. Navy NSGD 

8C. Testing-I-Chair: Captain Thomas M. Pigoski, U.S. Navy NSGD 

9A. Software Metrics-Chair: David Card, Computer Sciences 
Corporation 

9B. Education and Training-Chair: David Beilin, Pratt Institute 

9C. Testing-II—Chair: Captain Thomas M. Pigoski, U.S. Navy NSGD 


The conference will end with a plenary panel session entitled “CSM: A Look Into The Future. The panel 
participants will be the conference General Chair, Robert S. Arnold, and the Pogram Co-Chairs Thomas A. Corbi 
, and Wilma M. Osborne. 

The conference will adjourn at 12:30 pm on Thursday, October 27. 
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Three-dimensional computer performance 


Measuring computer performance by 
focusing on CPU performance 
expressed in MIPS (millions of instruc¬ 
tions per second) has led to numerous 
advances, such as multiprocessing, par¬ 
allel processing, and array and vector 
processing. However, performance of 
general-purpose computers depends by 
definition on the applications they are 
attempting to solve. No general-purpose 
computer will perform at the same level 
for all applications. Therefore, CPU 
performance alone is an inadequate 
measure of computer performance, 
especially in the arena of extensive I/O 
processing such as real-time computing. 
We need a three-dimensional measure 
of overall computer-response per¬ 
formance. 

A computer architecture that relies 
heavily on CPU performance needs to 
balance its internal design to satisfy the 
fast response of the overall computer 
system. Hypercubes, for example, 
which have powerful message-passing 
array-processing units linked in a cube 
with no common memory, will disinte¬ 
grate rapidly to an external interrupt to 
the computer. Therefore, CPU perfor¬ 
mance must become one of three 
measures—or dimensions—of system 
performance. The two other dimensions 
are high I/O throughput and high 
interrupt-handling capability. 

We define a 3D computer as a system 
capable of receiving inputs from an 
external real-world process, performing 
the required data processing, and out- 
putting the response back to the process 
fast enough to meet process require¬ 
ments. In addition, a 3D computer must 
be able to respond to external interrupts 
generated by I/O devices and other 
systems. 

Therefore, a 3D computer can be 
characterized by three key features: 

(1) sufficient speed of CPU compu¬ 
tation 

(2) an efficient interrupt-handling 
capability 

(3) high I/O throughput 


M 3 measure 

The performance of general-purpose 
computers is typically measured in 
terms of MIPS or Mflops (millions of 
floating-point operations per second). 
However, a 3D computer may have 
high CPU performance in MIPS, but 
poor interrupt-service capability and 
low I/O throughput. Therefore, we 
propose a measure that better suits 3D 
computers and takes into account all 
three features mentioned above. If we 
measure CPU speed in MIPS-1, 
interrupt-handling capability in MIPS-2 
(millions of interrupts per second), and 
I/O throughput in MIPS-3 (millions of 
I/O per second), then the proposed 
measure that incorporates all three fea¬ 
tures will be MIPS 3 or M 3 . 

The range of values for M 3 in 
advanced 3D computers is 

•CPU speed: 2-60 MIPS-1 

• interrupt-handling capability: 

.01-.2 MIPS-2, and 

• I/O throughput: 1-10 MIPS-3. 

These three features are not indepen¬ 
dent and should be analyzed together. 
For example, if a 3D computer has the 
following as its maximum features: 

• CPU speed: 5 MIPS-1 

• interrupt-handling capability: 0.1 
MIPS-2, and 


• I/O throughput: 5 MIPS-3 
it does not mean that these three fea¬ 
tures can be achieved simultaneously. 

In fact, increasing one feature automat¬ 
ically degrades the other two. There¬ 
fore, to accomplish a 3D architecture 
and provide a faster overall system 
response, all M 3 components need to 
improve. 

Let’s ignore I/O throughput for a 
moment and analyze the relationship 
between CPU speed and interrupt¬ 
handling capability. This analysis is 
possible because most modern 3D com¬ 
puters have separate processors to han¬ 
dle I/O operations, so I/O throughput 
depends very little on the other two 
features. 

Figure 1 shows a typical interdepen¬ 
dence between CPU speed and 
interrupt-handling capability for a 3D 
and a non-3D computer. Note that 
CPU power decreases in both cases 
when interrupt loading increases. How¬ 
ever, the performance of a non-3D 
computer degrades much faster than 
that of a 3D computer. 

Assuming a conventional computer in 
which a single CPU performs applica¬ 
tion programs and I/O processing, we 
can represent the M 3 measure as a plane 
in a three-dimensional space, as shown 
in Figure 2. 



MIPS-2 (Interrupt handling capability) 


Figure 1. Typical interdependence between CPU speed and interrupt-handling 
capability for a 3D and a non-3D computer. 
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Benchmarks 

In a single-task environment, stan¬ 
dard benchmark programs such as 
Whetstone, Dhrystone, and Linpack 
typically measure just the CPU speed. 
To measure the system response and 
performance of 3D computers, new 
types of benchmarks should be devel¬ 
oped. We have developed the M 3 bench¬ 
mark, which simulates a 3D 
environment and measures CPU speed 
as a function of interrupt loading. It 
consists of a combination of hardware 
and software elements: 

(1) a pulse generator to generate 
interrupts at user-selectable fre¬ 
quencies, 

(2) a user-coded interrupt-handler 
routine, and 

(3) the Whetstone benchmark. 

The M 3 benchmark was run for vari¬ 
ous interrupt-loading factors between 
zero and 100,000 interrupts per second 
on two Modcomp Classic CPUs: the CL 
11/75 and the CL 32/85. We used the 
MAX IV and MAX-32 real-time operat¬ 
ing systems, respectively. Figure 3 
shows the relative system performance. 

In addition to relative performance, 
two other measures are useful for 3D 
computers: program overhead and sys¬ 
tem overhead. 

Program overhead (P) is a measure 
that defines how much time it takes to 
complete an application program at a 
specific interrupt-loading compared to 
the time it takes to complete it at no 
interrupt-loading: 

P = -^- 2 - 100 [%] 

where t„ is the execution time under no 
interrupt-loading, and t„ is the execu¬ 
tion time at a particular interrupt¬ 
loading. 

Suppose that a benchmark program 
completes in one second at an interrupt¬ 
loading of zero, and in 1.6 seconds at 
an interrupt-loading of 20,000 inter¬ 
rupts per second. The program over¬ 
head for this interrupt loading becomes 

1.6- 1 

P20.000 = —— 100 = 60% 

In other words, this benchmark took 60 
percent longer to complete under the 
specified interrupt-loading. 

System overhead ( S) defines what 
percentage of the total elapsed time is 
devoted to handling interrupts: 

S = 100 [%] 

Using the same values as in the previ¬ 
ous example, S becomes 


1.6—.1 

S20.000 = 100 = 37.5% 

The obtained results for S show that the 
interrupt-handler spends 37.5 percent of 
the total elapsed time servicing inter¬ 
rupts, and the rest dedicated to the 
application program. 

When measuring the performance of 
3D computers, we can calculate the pro¬ 
gram and system overhead for different 
interrupt-loading. Note that S can be 
larger than 100 percent, in which case 
the saturation point has been reached. 

While the M 3 measurements reflect 
the three-dimensional nature of the 
computer, a simplified measure, called 
“big M,” can represent a single factor 
combining MIPS-1, MIPS-2, and 
MIPS-3. First, we can transform the 
three-dimensional measure from Figure 
2 into a two-dimensional measure, 
showing a vertical axis for the CPU 


speed in MIPS-1 and a horizontal axis 
for task/seconds (combining interrupt 
capability and I/O throughput). We 
then define “big M” as an equivalent 
MIPS that combines MIPS-1, MIPS-2, 
and MIPS-3. 

As advanced 3D computers become 
more complex, with multiprocessing, 
parallel processing, array processing, 
etc., it is important to develop a good, 
novel 3D architecture and a realistic 
methodology to evaluate and objec¬ 
tively measure M 3 of future 3D com¬ 
puters. A future issue of Computer 
Architecture News will describe and 
show results from a novel computer 
architecture using the 3D concept. 

Guy Rabbat, 

Borko Furht, 

Ronald Kibler 

Modcomp/AEG, Ft. Lauderdale, 
Fla. 



Figure 2. The M 3 measure, represented as a plane in a three-dimensional space, for 
a 3D computer and a non-3D computer. 
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STANDARDS 


Editor: Helen M. Wood, National Bureau of Standards, B154 Technology, Gaithersburg, MD 20899; (301) 975-3240 


Foundation to advance standards, develop open software environment 


Seven leading computer companies 
have established an international foun¬ 
dation to provide a completely open 
software environment designed to facili¬ 
tate customer use of computers and 
software from many vendors. 

The Open Software Foundation will 
develop a software environment, 
including application interfaces, 
advanced system extensions, and a new 
operating system using the specifica¬ 
tions for X/Open and Portable Operat¬ 
ing System Interface for Computer 
Environments (Posix) as the starting 
point. The Posix standard, developed 
by the Computer Society’s Technical 
Committee on Operating Systems and 
closely related to the Unix system, 
specifies how software should be writ¬ 
ten to run on computers from different 
vendors. 

Initial OSF funding is being provided 
by Apollo Computer, Groupe Bull, DEC, 
Hewlett-Packard, IBM, Nixdorf Com¬ 
puter AG, and Siemens Aktiengesell- 
schaft. Membership is available around 
the world to computer hardware and 
software suppliers, educational institu- 


X3, the Accredited Standards Com¬ 
mittee on Information Processing Sys¬ 
tems, has established Technical 
Committee X3J15, Programming Lan¬ 
guage Databus. The TC was formed to 
develop an American National Stan¬ 
dard on Databus and gather various 
Databus community interests into a sin¬ 
gle unit to further the standardization 
effort. 

Databus is a general-purpose business 
programming language used to write 
interactive applications for a variety of 
business computers. After Databus was 
introduced in 1972, numerous vendors 
implemented versions of the language 
for use on various types of hardware 
and with various operating systems. 

The expanding use of the language and 
the increasing number of Databus 
implementation vendors are indications 
of the need for a single, clearly defined 
standard. 


dons, governmental agencies, and other 
organizations. 

The foundation is launching opera¬ 
tions with over $90 million in funding. 
Initial development will be based on 
technologies offered by the members 
and its own worldwide research. 

“Creation of a standard software 
environment is one of the most impor¬ 
tant issues facing the computer industry 
today,” said John Doyle, foundation 
board chair. “This foundation fulfills 
the critical need for an open, rational, 
and equitable process to help establish 
the standards our customers demand 
and to protect their long-term software 
investments.” 

OSF is incorporated as a nonprofit 
research and development organization. 
It will define specifications, develop a 
leadership operating system, and pro¬ 
mote an open, portable application 
environment. To support the latter, the 
foundation will provide software that 
makes it easier for users to mix and 
match computers and applications from 
different suppliers by addressing the 
following needs: 


Versions of the Databus language are 
very similar at the application program¬ 
ming level. Certain implementations 
include enhancements and extensions 
that may be incorporated into the Data¬ 
bus standard. 

Adoption of an Databus standard 
would reduce the expense and time 
required to learn a particular version of 
the language, would improve portability 
of programs, and would promote 
production of educational documents 
and manuals useful with any standard 
implementation. 

X3J15 conducted its first meeting in 
May and plans to complete the draft 
standard by the end of 1990. Interested 
participants and users are invited to get 
involved in the Databus standard effort 
as soon as possible by contacting John 
Perkins, Datapoint, 9725 Datapoint 
Dr., MS S-37, San Antonio, TX 
78284-2097, phone (512) 699-7371 or 2. 


• portability—the capacity to use 
application software on computers 
from multiple vendors; 

• interoperability—the capacity to 
have computers from different ven¬ 
dors work together; and 

• scalability—the capacity to use the 
same software environment on 
many classes of computers, from 
personal to super. 

To achieve maximum acceptance for 
the new software environment, the 
foundation will provide all members 
with early and equal access to the devel¬ 
opment process. 

The OSF will follow a direction con¬ 
sistent with the international X/Open 
Common Application Environment, the 
National Bureau of Standards Applica¬ 
tion Portability Profile, and equivalent 
European and international standards. 
The foundation will work with standards 
groups to help define standards where 
they don’t exist. 

OSF members will be encouraged to 
contribute ideas on technical as well as 
policy matters, will be informed of 
foundation activities on a regular basis, 
and will be periodically polled on spe¬ 
cific issues. 

An institute is being created to fund 
and conduct research to enhance appli¬ 
cation portability, interoperability stan¬ 
dards, and other advanced technologies 
for future foundation use. An academic 
advisory panel will provide guidance 
and input to the institute. 

The initial set of interfaces will sup¬ 
port Posix and X/Open specifications 
and will be extended to include areas 
such as distributed computing, graphics, 
and user interfaces. 

To provide a clear and easy migration 
path for application developers and end 
users, the foundation’s system will 
include features to support current Sys¬ 
tem V- and Berkeley-based Unix appli¬ 
cations. The operating system will use 
core technology from a future version 
of IBM’s AIX operating system as a 
development base. 

Additional information may be 
obtained by contacting Open Software 
Foundation, PO Box 545, Billerica, MA 
01821, phone (617) 250-0035; or by call¬ 
ing Deborah Siegel, Cohn & Wolfe, 
(212)951-8300. 


Committee seeks help developing 
Databus language standard 
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Work launched to develop open distributed processing model 


Accredited Standards Committee X3 
of the American National Standards 
Institute has approved a new work item 
to generate a basic reference model of 
open distributed processing. This model 
will guide future work toward the devel¬ 
opment of a set of standards creating a 
unified distributed applications and dis¬ 
tributed processing environment. 

The ability to distribute data and pro¬ 
cessing resources offers opportunities 
for new styles of information process¬ 
ing. These opportunities will be readily 
realized if the concept of open systems 
—as seen in Open Systems Interconnec¬ 
tion standards—is readily extended to 
cover not only the communication but 
also the total distributed processing 
environment. ODP is concerned with 
the general aspects and common fea¬ 
tures of distributed systems. 

The developed standard will provide 
common definitions of concepts and 
terms for distributed processing, a 
generalized model of distributed pro¬ 
cessing using these concepts and terms, 
and a general framework for identifying 
and relating ODP standards. A key 
component of the model will be iden¬ 
tifying recommended programmatic 
interfaces. 

ODP will facilitate consistent defini¬ 
tion of additional models covering spe¬ 
cific application areas (office systems, 
banking, factory automation, etc.). 

Development of the basic reference 
model of ODP is the initial task the 


Standards Briefs 

VDT workstation design standard 
accepted. The American National Stan¬ 
dards Institute has accepted a new stan¬ 
dard entitled ANSI/HFS 100-1988, 
Human Factors Engineering of Visual 
Display Terminal Workstations. 

The 19-member VDT standards com¬ 
mittee of the Human Factors Society 
worked for six years developing, dis¬ 
cussing, and revising the proposed stan¬ 
dard before it was accepted by the 
ANSI. 

The new standard contains nearly 100 
mandatory specifications for the design 
of VDTs and workplaces that are 
optimally productive and comfortable 
for seated operators performing tasks 
such as text processing, data entry, and 
data inquiry. 

Major sections cover the working 
environment (including lighting, noise. 


ODP development group, called 
ISO/IEC JTC1, will undertake. This 
model will form the basis for future 
development of other ODP standards. 
Consensus will be developed among 
international experts on these primary 
topics: 

(1) The problem of distributed pro¬ 
cessing, involving requirements and 
benefits. 

(2) Basic definitions and properties 
resulting from distributed processing. 

(3) The structure of ODP standards, 
encompassing definitions, relationships, 
and interfaces between generic and 
application-specific services. 

(4) Modeling techniques, including 
formulation of a model of the use of 


Following publication of IEEE Std 
1016-1987 that outlines software design 
description information requirements, 
Working Group P1016.2 has begun 
developing a guide to such descriptions. 
The standard, Recommended Practice 
for Software Design Descriptions, was 
published in the spring of 1987. 

The guide will describe the relation¬ 
ship between IEEE Std 1016 and several 
popular design methodologies, and will 
propose tables of contents for design 
documentation. 


and temperature); visual display (reso¬ 
lution, color use, flicker, glare, and 
character height); keyboard (layout, 
height and slope, spacing, travel, etc.); 
furniture (clearances, surfaces, seating, 
accessories); and measurement tech¬ 
niques. 

To obtain additional information or 
to order copies, contact the Human 
Factors Society, PO Box 1369, Santa 
Monica, CA 90406, phone (213) 
394-1811 or 9793. 

IIA establishes voice standards task 
forces. The Information Industry Asso¬ 
ciation has announced formation of a 
Voice Information Services Technical 
Standards Committee and four task 
forces to promote development of rele¬ 
vant standards. 

Committee Chair Bob Ross said the 


the proposed distributed processing 
service. 

Development of US input to the 
International Organization for Stan¬ 
dardization/International Electrotech¬ 
nical Commission meetings has been 
assigned to X3T5.1, an X3 subgroup 
responsible for OSI architecture. 

X3T5 is seeking additional experts to 
actively participate in X3T5.1 on for¬ 
mation of the ODP model. Those 
interested should contact either John 
Day, Codex, 7 Blue Hill River Rd., 
Canton, MA 02021, phone (617) 
364-2000; or Jack Veenstra, AT&T Bell 
Laboratories, 1M-217, Crawfords Cor¬ 
ner Rd., Holmdel, NJ 07733, phone 
(201) 949-8979. 


WG P1016.2 plans to meet about 
four times a year, and development of 
the guide is expected to take two years. 
The group’s next two meetings are 
scheduled for July 7-8 in Toronto, 
Canada, and mid-October in Reno, 
Nevada. 

Those interested in participating in 
this group are asked to contact John 
McArdle, MacDonald Dettwiler and 
Associates, 3751 Shell Rd., Richmond, 
BC, Canada V6X 2Z9, phone (604) 
278-3411. 


panel’s objective will be to “develop 
and promote uniform specifications for 
the voice information services industry 
for use in the areas of technical and 
human interfaces, and to recommend 
these specifications to appropriate 
standards-making bodies.” 

The task forces assigned to lead the 
committee’s work include the Voice 
Processing System (VPS) Switch Speci¬ 
fication Task Force, the VPS Interoper¬ 
ability Task Force, the VPS/Database 
Access Specifications Task Force, and 
the Human Interface Specifications 
Task Force. 

The committee intends to convey its 
recommendations to key standards bod¬ 
ies and present proposals to the appro¬ 
priate American National Standards 
Institute committee within the next nine 
months. 


Working group developing guide 
to software design descriptions 
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Board of Governors approves slate of candidates for fall election 


At its June 17 meeting in Anaheim, 
California, the Board of Governors 
approved a slate of candidates for three 
Computer Society offices and 14 board 
positions to be filled by membership 
vote this fall. 

The seven highest vote-getters among 
the 23 candidates for Board of Gover¬ 
nors will serve three-year terms begin¬ 
ning January 1, 1989; the seven next 
highest will serve two-year terms. This 
procedure begins the transition from a 
20-member board of two-year positions 
to a 21-member board of three-year 
positions, as specified in the constitu¬ 
tional amendment passed in the fall 
1987 election (see Computer, August 
1987, p. 101, for details). 

The candidates are as follows: 


1989 president-elect (1990 president) 
Helen M. Wood 


1989 first vice president 
Barry Johnson 
Joseph E. Urban 


1989 second vice president 
Gerald L. Engel 
Laurel V. Kaleda 

1989-90 or 1989-91 Board of Governors 

Tilak Agerwala 
Vishwani Agrawal 
Mario Barbacci 
Bruce P. Berra 
Paul L. Borrill 
Bill P. Buckles 
Jon T. Butler 
Michael Evangelist 
Ronald G. Hoelzeman 
Se June Hong 
Tadao Ichikawa 
Sushil Jajodia 
Ted Lewis 
Ming T. Liu 
Ray M. Miller 
Yale Patt 
Earl Swartzlander 
Donald E. Thomas, Jr. 

Jacques Tiberghien 
Mario Tokoro 
Ben Wah 
Ronald Waxman 
Thomas W. Williams 


Additional nominees can be added to 
the ballot by membership petition (see 
Computer, February 1988, p. 79, for a 
complete list of Computer Society 
requirements for petition candidates). 
Petition candidates must submit their 
petition signatures (250 voting members 
for officer nominees, 50 voting mem¬ 
bers for Board of Governors nominees) 
and their biographical data, photo¬ 
graphs, and position statements to the 
Computer Society secretary at the fol¬ 
lowing address on or before August 1, 
1988: 

Duncan H. Lawrie 
Computer Society Secretary 
University of Illinois 
305 Talbot Laboratory 
104 S. Wright St. 

Urbana, IL 61801 

Candidates’ statements and 
biographical data will be published in 
the September 1988 issue of Computer 
and will be included in the September 2, 
1988, IEEE ballot mailing. Length limi¬ 
tations for these materials are as 
follows: 

Candidates ’ statements 
President-elect 350 words 

Vice president 250 words 

Board of Governors 150 words 

Biographical data 

All candidates 200 words 

Biographical sketches should cover 
the following topics in the sequence 
listed: 

• Computer Society activities 

• Other professional activities 

• Current employment, professional 
experience, and accomplishments 

• Degree(s) and major(s) 

• Awards and honors 
Nominees should also submit black- 

and-white passport-type photographs of 
themselves for publication along with 
their statements and biographies. 


New ‘cs.help’ mailbox 
speeds ombudsman solutions 

Computer Society members experiencing problems related to their mem¬ 
bership — dues, membership status, subscriptions, invoices, renewals — can 
now contact the Computer Society ombudsman electronically. 

A new address, cs.help, has been added to the society’s Compmail + elec¬ 
tronic mail system. This mailbox is checked daily by the membership staff. 
The problems are either handled immediately or, when procedures for appeal 
are needed, forwarded to the society’s ombudsman, Raymon Oberly, for for¬ 
mal action. 

Members who do not subscribe to Compmail + or whose complaint 
involves a Compmail + dysfunction should continue to write to the ombuds¬ 
man in care of the Computer Society Publications Office, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 90720. 
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Chapters invited to organize, host any of 14 CS tutorials 


Fourteen tutorials, some up to seven 
hours long and all available for presen¬ 
tation any day of the week, can now be 
arranged by local Computer Society 
chapters through the society’s Washing¬ 
ton, DC, office. 

Launched in the early 1980s, the 
Chapter Tutorial Program provides a 
moderately priced way for members to 
learn about a variety of subjects and 
simultaneously generate chapter 
income. 

The following are the currently avail¬ 
able tutorials and the individuals who 
will present them: 

• “Parallel Architectures and Sym¬ 
bolic Programming,” Joseph Bran¬ 
denburg, Intel Scientific 
Computers. 

• “Molecular Computing and Evolu¬ 
tionary Programming,” Michael 
Conrad, Computer Science and 
Biological Sciences Departments, 
Wayne State University. 

• “Fault Simulation and Test Gener¬ 
ation,” J. Max Cortner, Defense 
Systems Operations, Unisys. 

• “The Design/Test Trade-Off,” J. 
Max Cortner, Defense Systems 
Operations, Unisys. 

• “Introduction to Neural Net¬ 
works,” Maureen Caudill, 
Adaptics. 

• “Language-Directed Architecture 
and Object-Oriented Architec¬ 
ture,” Krishna M. Kavi, Depart¬ 
ment of Computer Science 
Engineering, University of Texas at 
Arlington. 

• “Application of Artificial Intelli¬ 
gence to the VLSI Test Genera¬ 
tion,” Ytzhak H. Levendel, AT&T 
Bell Laboratories. 

• “Automated Tools for Software 
Engineering,” Edward F. Miller, 
Jr., Software Research Inc. 

• “Software Testing,” Edward F. 
Miller, Jr., Software Research Inc. 

• “Computer Architecture Choices,” 
Yale N. Patt, University of Califor¬ 
nia at Berkeley and San Francisco 
State University. 

• “An Introduction to Prolog,” Jean 
Rogers, Computer Science Depart¬ 
ment, Stanford University. 

• “Introduction to Unix Shell,” 
Susan L. Rosenbaum, Practical 
Solutions International. 


• “Knowledge Representation,” 
John F. Sowa, IBM Systems 
Research Institute. 

• “Artificial Intelligence Program¬ 
ming,” Stephen Zvolner, Cor¬ 
porate Systems Development 
Division, Honeywell. 

Tutorials that turn a profit earn local 
chapters half of the proceeds, with the 
remaining 50 percent going to support 
continued development of the national 
program. The society absorbs the loss 


Daniel P. Siewiorek, a professor at 
Carnegie Mellon University and a mem¬ 
ber of the Computer Society, received 
the 1988 Eckert-Mauchly Award June 
1. The award is presented jointly by the 
society and the ACM for outstanding 
contributions to the field of computer 
architecture. 

This year’s Eckert-Mauchly selection 
committee chair, Zary Segall of CMU, 
made the presentation in Honolulu at 
the 15th annual International Sympo¬ 
sium on Computer Architecture. 

Siewiorek has been a member of the 
departments of Computer Science and 
Electrical Engineering at CMU since 
1972. The primary thrust of his research 
has been on reliability, particularly in 
regard to multiprocessor systems. 

At CMU, Siewiorek has had experi¬ 
ence on three generations of systems, 
first participating in the C.mmp proj¬ 
ect, next helping launch and direct Cm* 
for a 50-processor multimicroprocessor 
system, and then playing a major role 
leading to construction of C.vmp. 

The C.mmp project helped isolate 
and define the reliability problems, 
while Cm* opened the way to build 
large distributed systems, not necessar¬ 
ily with reliability as a goal. 

The third system, C.vmp, constitutes 
his contribution to the implementation 
of reliable distributed systems. C.vmp is 
a practical implementation of voting 
redundancy in the hardware, using very 
sophisticated design techniques for syn¬ 
chronization and failure recovery. 

Siewiorek has also been active in the 
Army/Navy Military Computer Family 
project to select a standard instruction 
set. 

He was elected a fellow of the IEEE 
in 1981 for contributions to the design 


when a chapter tutorial fails to make a 
profit. 

A kit is available containing informa¬ 
tion and forms needed to successfully 
stage a chapter tutorial; the kit includes 
such items as a timetable and a host 
chapter’s checklist. 

To obtain the kit and/or more infor¬ 
mation, contact David Barber, Com¬ 
puter Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, 
phone (202) 371-0101, ext. 232. 



Daniel P. Siewiorek was presented the 
1988 Eckert-Mauchly Award June 1 
in Honolulu. 


of modular computing systems and was 
awarded the Frederick Emmons Ter- 
man Award of the American Society of 
Engineering Education in 1983. He for¬ 
merly chaired the Computer Society’s 
Technical Committee on Fault-Tolerant 
Computing and has served as associate 
editor of the Computer System Depart¬ 
ment for the Communications of the 
ACM. 

He received the BS degree in electrical 
engineering (summa cum laude) from 
the University of Michigan in 1968 and 
both the MS and PhD degrees in electri¬ 
cal engineering from Stanford Univer¬ 
sity in 1969 and 1972, respectively. 


Eckert-Mauchly Award for 1988 goes to Siewiorek 
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Computer Society committee roster; 
complete directory now available 


A new directory of Computer Society 
volunteer leaders and staff is now 
available. 

The directory lists the society’s 
officers, board members, committee 
chairs, and representatives. Much of 
that information is reproduced below 
and on the Computer Society Informa- 


STANDING COMMITTEES 
Audit: Paul L. Borrill 

Awards: Claud M. Davis 
A wards Policy: Ned Kornfield 
Eckert-Mauchly: Jack Lipovski 
W. Wallace McDowell: Rex Rice 
Technical Achievement: L. Charles Hobbs 
Computer Pioneer: Ralph Preiss (acting) 
Computer Entrepreneur: Arthur Pohm 
Externa! Awards Search: Claud M. Davis 
Society Search: Tse-yun Feng 
Richard E. Merwin/Distinguished Service: 
Samuel Horvitz 
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Meritorious Service: Ralph Preiss 
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Constitution and Bylaws: Kenneth R. 
Anderson 

Elections: Wing N. Toy 
Fellows: Tilak Agerwala 
Finance: Barry W. Johnson 
Intersociety Cooperation: Jon Butler 
Nominations: Roy L. Russo 

Operations: Edward A. Parrish, Jr. 
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European Activities: Jacques Tiberghien 
Asian Activities: Akihiko Yamada 
Computer Services Advisory: Charles B. 
Silio 

Long Range Planning: Kenneth R. Anderson 

Personnel and Compensation: Kenneth R. 
Anderson 

Computer Society History: Stephen S. Yau 


AD HOC COMMITTEES 

CS/DAC Coordination: Roy L. Russo 


AREA ACTIVITIES BOARD 

Vice president: Willis K. King 
Vice chair: Alicja I. Ellis 


tion Page (inside back cover), but the 
directory also includes addresses and 
phone numbers and gives both staff and 
volunteer contacts for specific services 
and information. 

To obtain a copy of the directory, use 
the Reader Service Card at the back of 
this magazine, circling number 196. 


Secretary: Keith Barker 

Staff newsletter editor: David Barber 

Area Committee chairs 

Region 1, Northeastern: K.R.S. Murthy 
Region 2, Mideastern /Ohio Valley: Paul Hulina 
Region 3, Southeastern: Brian Petrasko 
Region 4, Midwestern: J. Max Cortner 
Region 5, Southwestern: Arthur Alterman 
Region 6, Pacific: Steve Kuan 
Region 7, Canada: Micha Avni 
Region 8, European Area: Michel Israel 
Region 9, Latin America: Carlos Fronterotta 
Region 10, Eastern Hemisphere: V. Namakkal 
Balasubramanian 

Newsletter editor: Teodor Rus 

New Chapter Development: Willis K. King 

Chapter/Video Tutorials: Alicja I. Ellis 

Distinguished Visitors Program: Tse-yun Feng 

Student Activities: Murali Varanasi 

New Activities: Keith Barker 

Finance Committee representative: Willis K. 

King 


CHAPTER CHAIRS 

Region 1, Northeastern 

Berkshire: Bertram J. Pritchard 
Binghamton: John F. Florio 
Boston: Charles F. Crabb 
Buffalo: William C. Schultz 
Connecticut: Ron Nilsen 
Long Island: Grigor Baron-Vartian 
Maine: 

Mid-Hudson: 

Mohawk Valley: Stuart W. Card 
New Hampshire: Steven Simmons 
New Jersey Coast: Edwin McCrohan 
New York: Bertil Lindberg 
North Jersey: David P. Perry 
Princeton: Douglas F. Dixon 
Rochester: Paul D. Conaway 
Schenectady: Steven W. Hammond 
Syracuse: Mark Schafer 
Worcester: James Chelini 


Region 2, Mideastern/Ohio Valley 

Akron: Stephen J. Alexander 
Baltimore: Allan B. Anderson 
Canton: 

Cleveland: 

Columbus: 

Dayton: Tim Glaze 

Delaware Bay and Newark: Ronald K. Pearson 


Eastern Shore: Lee S. Anderson 
Lehigh Valley: 

Northern Virginia: H.R. Cole, Jr. 
Philadelphia: James Kubeck 
Pittsburgh: Neena Lakhavani 
Washington: Glenn C. Hughes II 

Region 3, Southeastern 

Alabama: James H. Pate 
Atlanta: Randall D. Dunlap 
Broward: Jacques Levine 
Canaveral: 

Central Georgia: 

Charlotte: John Jacomino 

East Tennessee/Oak Ridge: Robert W. Rochelle 

Florida West Coast: 

Hampton Roads: James E. Sandstrom 
Huntsville: Carol Y. Workman 
Louisville: Joseph D. Cole 
Miami: Edward Lee 
Nashville: Leehyun Keel 
New Orleans: Tom Slack 
Orlando: Jorge N. Medina 
Palm Beach: Eduardo Fernandez 
Tri Cities: James G. Huff 
Virginia Mountain: T.C. Poon 

Region 4, Midwestern 

Calumet: Gary D. Arnott 
Cedar Rapids: Glenn A. Myers 
Central Indiana: 

Chicago: Alan Nelles 

Fort Wayne: E. P. Slick 

Illinois Valley: Thomas L. Stewart 

Milwaukee: Ted J. Kucharski 

Nebraska: Roy F. Keller 

Southeastern Michigan: Wayne Coste 

Southern Minnesota (Rochester): David Geller 

Toledo: Ezzatollah Salari 

Twin Cities: Christine Schorber 

Region 5, Southwestern 

Arkansas: Patricia S. Buford 
Central Texas: 

Corpus Christi: Willie D. Clayton 
Dallas: Rajendra S. Wall 
Denver: Sandra Bish 
Fort Worth: Hal C. Ferguson 
Galveston Bay: Gary Raines 
Houston: Ernst L. Leiss 
Oklahoma City: 

Pikes Peak: R. Dandapani 
St. Louis: Paul T. Smith 
Wichita: Mark M. Jong 

Region 6, Pacific 

Albuquerque: John J. McDermott 
China Lake: David Koelsch 
Fort Huachuca: 

Los Angeles Council: Moro Dentino 
Phoenix: 

Portland: Daniel Garigan 
Richland: Manolo Juguilon 
Sacramento: Suresh K. Vadhva 
Santa Clara/San Francisco/Oakland: 

San Diego: Carl Gerle 
Santa Monica Bay: Irving Doshay 
Seattle: Lisa Romjue 
Spokane: Leonard I. Byrne 

Utah: 

Region 7, Canada 

Canadian Atlantic: Alphonsus L. Dunphy 
Hamilton: Nathan Schachter 











Kitchener-Waterloo: Murray C. Bookman 
Montreal: Michel B. Fortier 
Northern Canada: Arnold E. Ness 
Ottawa: Faruk S. Hadziomerovic 
Quebec: Louis N. Belanger 
Southern Alberta: Graham Birtwhistle 
Toronto: Michael H.F. Weitz 
Vancouver: Fiorenza C. Albert-Howard 
Winnipeg: Bob McLeod 

Region 8, European Area 

Egypt: Abdel-Lati I. Ahmed 
France: Erol Gelenbe 
Germany (West): Robert L. Baber 
Israel: Jonah Z. Lavi 
Spain: Fernando S. Vacas 
Switzerland: George S. Moschytz 
United Kingdom and Republic of Ireland: 
Martin J. Bolton 

Region 9, Latin America 

Argentina: Herman E. Dolder 

Chile: Horacio R. Melendez 

Mexico: Jorge H. Flores Sanchez 

Panama: Lucas R. Halphen 

Puerto Rico and Caribbean: Luis T. Gandia 

Sao Paulo: Marcello J. Abbud 

Region 10, Eastern Hemisphere 

Bangalore: 

Bombay: P.K. Patwardhan 

Hong Kong: Wanbil W. Lee 

Kerala: K.T. Nair 

Korea: In Chil Lim 

Madras: V. Krishnamurthi 

New South Wales: Richard J. Marshall 

Singapore: 

Taipei: Chyan-Goei Chung 
Tokyo: Osamu Ishii 
Victoria: Herbert Stein 


CONFERENCES AND TUTORIALS 
BOARD 

Vice president: Joseph E. Urban 

Vice chair: Pei Hsia 

Secretary: Guylaine Pollock 

Director of conferences and tutorials: Anne 

Marie Kelly 

Committee chairs 

Compcon Spring: Sidney Fernbach 

Compsac: Stephen S. Yau 

Finance: Guylaine Pollock 

New Thrust Areas: Boumediene Belkhouche 

Planning/Self-Assessment: Duncan H. Lawrie 

Proposal Review: Edward T. Lee 

Regional Conferences: Mark Haas 

Tutorials: Teodor Rus 

IEEE TAB representative: Raymon P. Oberly 
Computer Society TAB representative: Paul 
Bardell 

Meeting representatives 

Artificial Intelligence Conference: Paul 
Harmon 

Design Automation Conference: Charles Radke 
CompEuro: Thomas Williams, Roberto 
Negrini, Hubert Kirrmann 
International Test Conference: Raymon P. 
Oberly 

SRDS: Ming T. Liu 

Winter Simulation Symposium: Sallie 

Sheppard 

Annual Simulation Symposium: Oryal Tanir 


TECHNICAL MEETING CHAIRS 

(for meetings after 5/1/88) 

ACM/CS Design Automation Conference: 
Dennis Shaklee 

Aerospace and Security Conference: 

Marshall Abrams 

Applied Imagery Pattern Recognition: 
Built-In Self Test Workshop: Richard Sedmak 
Compcon Spring: Hasan Al-Khatib 
CompEuro 89: Walter Proebster 
Compsac: Abe Peled 
Computer Networking Symposium: 
Computer Security Foundations Workshop: 
Jonathan K. Millen 
Computer Standards Conference: 

Conference on Artificial Intelligence: Elaine 
Kant 

Conference on Computer Vision and Pattern 
Recognition: Ramesh Jain 
Conference on Local Computer Networks: 
Ron Rutledge 

Conference on Office Information Systems: 
Conference on Software Maintenance: 

Robert S. Arnold 

Conference on Structure in Complexity 

Theory: Alan L. Selman 

Data Communications Symposium: 

Design Automation Workshop: Walling Cyre 
Expert Systems in Government: Jude Franklin 
Foundations of Computer Science: Christos 
Papadimitriou 

Frontiers 88: James R. Fischer 

IEEE European Workshop on Design for 

Testability: Thomas W. Williams 

IEEE Infocom: Ron Rutledge 

IEEE Internationl Conference on Ada 

Applications and Environments: Derek S. 

Morris 

IEEE Internationl Conference on Computer- 
Aided Design: A1 Jiminez 
IEEE International Symposium on Multiple- 
Valued Logic: Enric Trillas 
IEEE International Workshop on Software 
Specification and Design: Sol Greenspan 
IEEE Symposium on Mass-Storage Systems: 
Patric Savage 

IEEE Symposium on Security and Privacy: 
IEEE VLSI Test Workshop: Wesley C. 
Radcliffe 

International Conference on Computer 

Design: Prathima Agrawal 

International Test Conference: Camie Jackson 

International Conference on Computer 

Languages: Pei Hsia 

International Conference on Computer 

Vision: Ruzena Bajcsy 

International Conference on Data 

Engineering: 

International Conference on Distributed 
Computing Systems: Carl Davis 
International Conference on Software 
Engineering: Larry E. Druffel 
International Conference on Systolic Arrays: 
Keith Bromley 

International Conference on Very Large 
Databases: Jack E. Shemer 
International Conference on Wafer-Scale 
Integration: Earl Swartzlander 
International Symposium on Computer 
Architecture: H. J. Siegel 
International Symposium on Databases for 
Parallel and Distributed Systems: Joseph E. 
Urban 

International Symposium on Fault-Tolerant 


Computing: Yasuo Komaniya 
International Workshop on Defect and Fault 
Tolerance in VLSI: Israel Koren 
International Workshop on Transaction 
Machine Architecture: Martin Freeman 
Joint Logic Programming Meeting: Kenneth 
A. Bowen 

Personal Computing Workshop: 

Real-Time Systems Symposium: Walter 
Heimerdinger 

Software Process Workshop: Leon Osterweil 
Southeastern Symposium on Systems 
Theory: William A. Smith 
Supercomputing 88: George Michael 
Symposium on the Engineering of 
Computer-Based Medical Systems: John M. 
Long 

Symposium on Logic in Computer Science: 
A.K. Chandra 

Symposium on Reliable Distributed Systems: 
David Cohen 

Visualization of Info 89: Stephen Levine 
West Coast Test Workshop: 

Winter Simulation Symposium: 

Workshop on Computer Architecture for 
PAMI: 

Workshop on Fault Tolerance in Parallel 
and Distributed Computing: 

Workshop on Languages for Automation: 

Panos A. Ligomenides 

Workshop on Machine Vision: Jorge L.C. 

Sanz 

Workshop on Motion: Brian G. Schunck 
Workshop on Real-Time Operating Systems: 
John Stankovic 

Workshop on Software Testing, 

Verification, and Analysis: Lee J. White 


EDUCATIONAL ACTIVITIES BOARD 

Vice president: Gerald L. Engel 
Vice chair: Bruce H. Barnes 
Secretary: Rebecca A. Mahoney 
Newsletter editor: Harry Brearley 

Committee chairs 

CSAB Accreditation: Willis K. King 
ABET Accreditation: Fred Maryanski 
Laboratory Development: Keith Barker 
Curriculum Development: Bruce H. Barnes 
Information Systems Programs: John 
McGregor 


Representatives 

IEEEEAB: Gerald L. Engel 

Computer Engineering Departments: Bill D. 

Carroll 

Finance Committee: Gerald L. Engel 
Computer Magazine: Ronald G. Hoelzeman 
ICCP: Marshall Yovits, David H. Jacobsohn 
NECC: Michael C. Mulder 
Liberal Arts Accreditation: Gerald L. Engel 
MAA Task Force: G. Yeung, J. Gersting 
CSAB Board: J.T. Cain, Gerald L. Engel, 
Lansing Hatfield, Willis K. King (alt.), Glen 
G. Langdon, Jr., Michael C. Mulder (alt.) 


MEMBERSHIP AND INFORMATION 
ACTIVITIES BOARD 

Vice president: Merlin G. Smith 

Vice chair: Ned Kornfield 

Vice chair, membership: Barry W. Johnson 






Vice chair, information: Raymon P. Oberly 
Past vice president: Ming T. Liu 
Admissions Committee chair: Henry Chuang 
Membership Development Committee chair: 
Ronald D. Williams 

Public Policy Committee chair: Ralph Preiss 
At-large members: George I. Davida, Laurel 

V. Kaleda, Walter Kohler, Ted Lewis, David 
Pessel, Susan L. Rosenbaum, Roland Saam, 
Earl E. Swartzlander, Jr., Russel E. Theisen, 
Jacques Tiberghien, Akihiko Yamada 

Ombudsman: Raymon P. Oberly 
Staff coordinator: Christina Champion 

PUBLICATIONS BOARD 

Vice president: James Aylor 
Vice chair: Charles B. Silio 
Secretary: 

Editors-in-chief 

Computer: Bruce D. Shriver 
Computer Society Press: Ez Nahouraii 
IEEE Computer Graphics and Applications: 
John Staudhammer 

IEEE Design and Test of Computers: Sumit 
DasGupta 

IEEE Expert: David Pessel 

IEEE Micro: James J. Farrell III 

IEEE Software: Ted Lewis 

IEEE Transactions on Computers: Ming T. 

Liu 

IEEE Transactions on Pattern Analysis and 
Machine Intelligence: Steven L. Tanimoto 
IEEE Transactions on Software Engineering: 
Victor Basili 

IEEE Transactions on Knowledge and Data 
Engineering: C.V. Ramamoorthy 

Representatives and members at-large 

Finance Committee representative: Benjamin 

W. Wah 

IEEE Publications Board representative: 
James H. Aylor 

IEEE TAB Periodicals Committee: Samuel 
Horvitz 

CS TAB liaison: Sallie Sheppard 
At-large members: J. Richard Burke, Jon T. 
Butler, J.T. Cain, Michael Evangelist, Glen 
Langdon, Theo Pavlidis, Harold Stone 

Committee chairs 

Magazine Advisory: Sallie Sheppard 
Transactions Advisory: Theo Pavlidis 
Circulation Promotion/Advertising 
Advisory: Jon T. Butler 
Computer Society Press Advisory: Charles 
B. Silio 

Publications Planning: Richard Burke 


STANDARDS ACTIVITIES BOARD 

Vice president: Helen M. Wood 
Secretary: John W. Walz 
Treasurer: Peter Ron Prinzivalli 
Staff coordinator: Richard Cain 

Committee chairs 

Standards Coordinating: Paul L. Borrill 
Policy and Procedures: Paul L. Borrill 
Publicity: Jean Gilmore 
Conferences: Roger Martin 
Awards: Charles P. Hollocker 


International Standards Activities: Perry 
Operations: Ron Waxman 

Representatives to Computer Society 
committees 

Membership: Tom Kurihara 
Technical Activities Board: Allen L. 
Hankinson 

Public Policy: Tom Kurihara 

Technical committee sponsor representatives 

TC Computer Communications: Maris 
Graube 

TC Computer Languages: Teodor Rus 
Database Engineering: Krithi Ramaritham 
TC Design Automation: Ronald D. Waxman 
TC Microprocessors and Microcomputers: 
Michael Smolin 

TC Operating Systems: James Isaak 
TC Simulation: Oryal Tanir 
TC Software Engineering: Norman 
Schneidewind 

TC Test Technology: J. Reese Brown, Jr. 
Joint Pascal Committee: Michael Hagerty 

Appointed member: Sava I. Sherr 
TAB representative: Allen L. Hankinson 

Representatives to outside standards 
committees 

IEEE Standards Board: Helen M. Wood 
NESCOM: John Horch 
NOSCOM: Ronald D. Waxman 
X3 Standards Committee: Helen M. Wood 
ACM Standards Committee: Paul Borrill 
DoD Std. 2167A Committee: Allen 
Hankinson 

SCC 20 (Atlas): Ron Waxman 

JTC1 SC7 representatives on US Tags 
administered by the CS 

JTC1 SC7: Tom Kurihara, Roger Fujii, John 
Horch 

JTC1 SC22 WG 15 (Posix): James Isaak, 
Roger Martin, Hal Jesperson, Donn Terry 
JTC1 SC22 WG13 (Modulo): Randy Bush 

Liaison representatives 

ACM: John Klensin 
JTC1 7 SCI3: Gary Robinson 
X3: Gary Robinson 

STANDARDS COORDINATING 
COMMITTEE 

Chair: Paul Borrill 
Secretary: Jean Gilmore 

Standards subcommittee chairs 

Design Automation: Ronald D. Waxman 
802 (Local Area Networks): Maris Graube 
Microprocessor: Clyde Camp 
Operating Systems (1003): James Isaak 
Software Engineering: John Horch 
Test Technology: J. Reese Brown, Jr. 

Standards working group chairs 

P610 Computer Terminology: Jane Radatz 
P662(R) Semiconductor Memory 
Terminology: J. Reese Brown, Jr. 

P695 Microprocessor Relocatable Software 
Format: Tom Pittman 
P696(R) Backplane Bus (S100): Richard 
Kalish 


P729(R) Software Engineering Terminology: 
Jane Radatz 

P755 High-Level Language Extensions for 
Micros: Richard James 
P770 Extended Pascal: Michael Hagerty 
P802.1 LAN—Architecture and Overview: 
William Lidinsky 

P802.3(R) LAN—CSMA/CD: Donald C. 
Loughry 

P802.4 LAN—Token-Passing Bus: Paul S. 
Eastman 

P802.5 LAN—Token-Ring Networks: Bob 
Donnan 

P802.6 LAN—Metropolitan Area Networks: 
James Mollenauer 

P802.7 LAN—Broadband Technical 
Advisory Group: Jim Montrose 
P802.7 LAN—Fiber Optics Technical 
Advisory Group: Terry Bowen 
P802.7 LAN—Integrated Voice and Data 
Networks: Keith Patterson 
P828(R) Software Configuration 
Management Plans: H. Ronald Berlack 
P829/R) Software Test Documentation: 
David Gelperin 

P849 Handler-Test Interface Signals: Ron 
Leckie 

P855 Microprocessor Operating Systems 
Interface: Jim Mooney 
P896.2 Future Bus Firmware: Paul Borrill 
P942 Semiconductor Device Test- 
Programming Language: J. Reese Brown, 

Jr. 

P949 Media Independent Information 

Transfer: J. Robert Davis 

P959 I/O Extension Bus: Steve Cooper 

P970 Advanced Backplane Bus: Doug Kraft 

P982 Standard Directory of Measures to 

Produce Reliable Software: James Dobbins 

P982.1 Guide to P982: James Dobbins 

P996 Extended Persona! Computer 

Backplane Bus: Gary Lyons 

PI003.0 Guide to Posix-Based Open Systems 

Architecture: James Isaak 

PI003.1 Portable Operating Systems (Posix): 

James Isaak 

P1003.2 Shell and Utility Application Inter¬ 
face: Hal Jesperson 
P1003.3 Test Methods for Measuring 
Conformance to Posix: Roger Martin 
P1003.4 Real-Time Posix Extensions: Bill 
Corwin 

P1003.5 Ada Language Binding for Posix: 
Terence Feng 

P1003.6 Security Interface Standards for 

Posix: Dennis Steinauer 

P1016.2 Guide to Software Design 

Descriptions: John McArdle 

PI028 Software Reviews and Audits: Charles 

Hollocker 

PI044 Classification of Software Errors, 

Faults, Failures: Dick Evans 

PI045 Software Productivity Metrics: 

Robert Sulgrove 

P1058.2 Software Project Management 
Plans: Richard Fairley 
PI059 Software Verification and Validation: 
Jerry Mersky 

PI061 Software Quality Metrics Methodol¬ 
ogy: Norman F. Schneidewind 
PI062 Software Certification: Philip C. 
Marriott 

P1074 Software Life-Cycle Process: David 
Schultz 

P1076(R) Description Language for Elec- 








tronic Hardware (VHDL): Larry Saunders 
PI077 Design Management: John Graham 
P1078 Information Model Description Lan¬ 
guage: Steven Piatz 
P1086 Computer Terminology — 

Applications Theory: Jane Radatz 
P1087 Computer Terminology—Hardware: 
Jane Radatz 

PI088 Computer Terminology- 

Environment: Jane Radatz 

P1096 Multiplexed High-Performance Bus 

Structure (VSB): Doug Kraft 

PI 132 VMS (IEC 823) Bus: Ad Willemse 

PI 141 Forth—A Microcomputer Language: 

Guy Kelley 

PI 149 Standard Testability Bus: Jon Turino 
PI 151 Modula-2: Randy Bush 
PI 152 Object-Oriented Programming Lan¬ 
guage: Peter Deutsch 

PI 154 Programmed Inquiry, Learning, or 

Teaching: John Starkweather 

PI 155 High-Speed Backplane 

Instrumentation Bus: Bill Maciejewski 

PI 156 Connectors and Mechanical 

Packaging for High-Reliability Bus 

Structures: Paul Cook 

PI 163 Intermediate Representation for 

VHDL: Paul Menchini 

PI 164 VHDL Recommended Coding 

Practices: Larry Saunders 

PI 165 Interrelationships Between VHDL 

and EDIF: Paul Stanford 

PI 173 Set of Functional Components of a 

Simulation Language: Oryal Tanir 

PI 175 Interconnections Among Computing 

Systems Engineering Tools: Robert Poston 

PI394 High-Performance Serial Backplane 

Bus: Michael Teener 

PI395 Physical I/O Configurations for 

Communications Switching Systems: Gary 

A. Nelson 

PI396 Communication Bus for Hybrid 
Switching Applications: Gary A. Nelson 
PI496 Rugged Bus— Very High Reliability 
Bus: Paul Cook 

TECHNICAL ACTIVITIES BOARD 

Operations Committee 

Vice president: Laurel V. Kaleda 
Vice chair: Mario Barbacci 
Past vice president: Kenneth R. Anderson 
Treasurer: Anneliese von Mayrhauser 
Staff coordinator: David Barber 
Member-at-large: Walter Vilkelis 
TAB Task Force, topics chairs 
Professional Tools: Robert Poston 
Global Change: Bernard O’Lear 
Telesatellite and Televideo: Paul Hazan 
Neural Nets: Kamal Kama 
Representatives 

Publications Board and Communications: 
Sallie Sheppard 

Finance Committee: Anneliese von Mayrhauser 

TAB Standards Development/CS Standards 

Board: Allen L. Hankinson 

IEEE Council on Robotics: Wesley Snyder 

IAPR: J.K. Aggarwal 

Solid State Circuits Council: Earl E. 

Swartzlander, Jr. 

Technical Committee chairs 
Computational Medicine: John M. Long 
Computer Architecture: Roger Anderson 


Computer Communications: William D. 
Livingston 

Computer and Display Ergonomics: James 
Greeson 

Computer Elements: Ronald Bell 
Computer Graphics: Lawrence J. Rosenblum 
Computer Languages: Pei Hsia 
Computer Packaging: Martin Freedman 
Computing and the Handicapped: Everett 
Johnson 

Computers in Education: Doris Carey 
Database Engineering: Sushil Jajodia 
Design Automation: Sumit DasGupta 
Distributed Processing: Walter Kohler 
Fault-Tolerant Computing: David A. Rennels 
Mass-Storage Systems: Patric Savage 
Mathematical Foundations of Computing: 
Christos Papadimitriou 
Microprogramming: 

Microprocessors and Microcomputers: 
Martin Freeman 

Multiple- Valued Logic: Michel Israel 
Oceanic Engineering and Technology: 
Michael Guberek 
Office Automation: David Choy 
Operating Systems: Joseph Boykin 
Optical Processing: Ravi Athale 
Pattern Analysis and Machine Intelligence: 
J.K. Aggarwal 

Personal Computing: Walter Beam 
Real-Time Systems: Andre van Tilborg 
Robotics: Mohan Trivedi 
Security and Privacy: Carl Landwehr 
Simulation: Heimo Adelsberger 
Software Engineering: Lorraine M. Duvall 
Supercomputing Applications: Joanne 
Martin 

Test Technology: Paul Bardell 
VLSI: Don Bouldin 

COMPUTER SOCIETY 
REPRESENTATIVES 

Society level: Edward A. Parrish, Jr. 

ACM: Oscar N. Garcia 

AFIPS: Kenneth R. Anderson 
Directors: Kenneth R. Anderson, Edward 
A. Parrish, Jr., Dick B. Simmons 
Executive Committee: Dick B. Simmons 
Admissions Committee: David H. Jacobsohn 
Nominations Committee: Edward A. 
Parrish, Jr. 

Education Committee: Gerald L. Engel 
Finance Committee: Barry W. Johnson 
Government Activities: 

Public Policy Committee Liaison: 
Constitution/Bylaws Committee: 

Conferences: Joseph E. Urban 
Annual Simulation Symposium: Sallie 
Sheppard 

Winter Simulation Symposium: Sallie 
Sheppard 

Western Committee: Doug Ciese 
ICCAD/ICCD Coordination Committee: 
Peter K. Wolff, Sr. 

CompEuro: Thomas Williams, Robert 
Negrini, Hubert Kirrmann 

Membership and Information: Merlin G. 
Smith 

IEEE TAB/USAB Aerospace R&D 
Committee: Russell E. Theisen 


IEEE TAB/USAB Engineering R&D 
Committee: Chester Carroll 
IEEE TAB/USAB Defense R&D 
Committee: Paul Hazan 
IEEE TAB/USAB Communications and 
Information Policy Committee: Claud M. 
Davis, Paul I. Davis 

IEEE TAB/USAB Professional Activities 
Council for Engineers (PACE): Ned 
Kornfield, Kenneth R. Anderson 
IEEE Health Care Engineering Policy: H. 
Troy Nagle, Jr. 

IEEE Society on Special Implications of 
Technology: Kazuhiko Kawamura 
Computer Museum: Ted Bonn 

Educational Activities: Gerald Engel 
Computer Sciences Accreditation Board: 
J.T. Cain, Stewart Eueben, Raymond 
Miller, Thomas Phillips 
Institute for Certification of Computer 
Professionals: Marshall Yovits, David H. 
Jacobsohn 

Publications: James H. Aylor, C. Lee Giles 

Standards: Helen M. Wood 
IEEE Standards Board: Helen M. Wood 

Technical Activities: Laurel V. Kaleda 
IEEE Council on Robotics and 
Automation: Wesley E. Snyder, Eric 
Grimson 

IEEE Solid State Circuits Council: Earl E. 
Swartzlander, Jr., Sol Triebwasser 
International Association for Pattern 
Recognition: Theo Pavlidis, J.K. Agrawal, 
Herbert Freeman, Robert Haralick 

IEEE DIVISION V REPRESENTATIVES 

Director: Harriett Rigas 

TAB Awards and Recognition: Dick B. 

Simmons 

TAB Meetings: Y.T. Chien 

IEEE Membership Development: Russell E. 

Theisen 

IEEE Publications Board: Steven Yau 
TAB Finance: Joseph E. Urban 
PACE coordinator: Charlie Rubinstein 
TAB Periodicals: Anil K. Jain 
Transnational Relations: Ed Jones 

IEEE DIVISION VIII 
REPRESENTATIVES 

Director: H. Troy Nagle, Jr. 

TAB A wards and Recognition: Ralph Preiss 
TAB Meetings: Raymon P. Oberly 
IEEE Membership Development: Raymon 
P. Oberly 

IEEE Publications Board: James H. Aylor 
IEEE Committee on Man and Radiation 
Energy: 

EAB correspondent representative: David 
Rubkeman 

TAB Finance: Joseph E. Urban 
PACE coordinator: Ned Kornfield 
TAB Periodicals: Samuel Horvitz 
TAB Search Committee: Oscar N. Garcia 
TAB New Technology Directions 
Committee: J. Richard Burke 
Transnational Relations: David Pessel 
Society for Social Implications of Technology: 
Kazuhiko Kawamura 








BLOCK 


TI/^INGi 
DIAGRAM | 


TO SYSTEM DESIGN SOLUTIONS 


Why nor rake the shortest and fastest route 
toward system design solutions? To define 
and model a large, complex system, you 
need a modeling tool that can address the 
system's total architecture. 

M PAWS/GPSM™ is an easy-to-use high 
productivity modeling and simulation 
tool that lets you evaluate alternative 
architectures while focusing on performance. 
It provides a state-of-the-art environment for 
developing accurate and reliable product 
definitions. 

Q 9 PAWS provides high level primitives 
closely resembling the user's intuition. 
PAWS models the behavior of a total 
system implemented in diverse technologies 
including software, hardware, and firmware. 

IRA 


GPSM, the graphical interface to 
PAWS, helps you quickly and easily 
transfer your ideas into pictures. GPSM 
helps you visualize multiple data and control 
flows through several components and 
incrementally synthesize models of a total 
system. 

%% PAWS/GPSM is flexible. It lets you refine 
your model as your system design 
evolves so you can eliminate potential 
problems as early as possible in the product 
design cycle. 

Call (512) 474-4526 to receive information 
on PAWS/GPSM. And get on the PAWS 
expressway to system design solutions. 

PAWS and GPSM are trademarks of Information Research Associates, Inc. 


Information Research Associates • 911 W. 29th St. • Austin, Texas 78705 • (512) 474-4526 
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Contributions to Update are welcome. Send news of industrial or university research and of public policy or professional issues to Update Editor, 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720, or to Bruce Shriver, Editor-in-Chief, Dept, of Decision Sciences, University of Hawaii, 2404 Maile Way, Honolulu, HI 96822. 


Sematech designates five university Centers of Excellence 


Sematech has designated five univer¬ 
sity Centers of Excellence to support the 
semiconductor manufacturing research 
consortium’s objective of restoring US 
leadership in semiconductor manufac¬ 
turing technology. 

Under a proposal submitted to the 
Texas-based consortium in April, the 
University of California’s Berkeley and 
Santa Barbara campuses will join with 
Stanford University as one of the five 
centers in a program of advanced 
research, technology transfer, and edu¬ 
cation. 

Also named as Centers for Excellence 
May 31 were the University of Arizona 
for contamination/defect control; a 
New Jersey group of universities for 
plasma etching; the University of New 
Mexico for metrology; and the Mas¬ 
sachusetts Microelectronics Center for 
single-wafer processing. 

The centers were selected by a team 
of 36 leading technical experts in the 
semiconductor industry. The experts 
based their review of proposals and 
selection of centers on the quality of the 
research program offered, its relevance 
to Sematech’s needs, and the nature of 
the program resources that would be 
made available at each center. 

“We expect that these centers will not 
only conduct meaningful research in 
advanced manufacturing sciences, but 
will also provide the US semiconductor 
industry with a new type of electrical or 
computer engineer trained in the science 
of manufacturing,” said Sanford L. 
Kane, who chairs the Sematech execu¬ 
tive committee. 

“Sematech’s primary goal for estab¬ 
lishing these centers is to provide focus 
for development of manufacturing pro¬ 
grams within graduate schools of US 
universities.” 

Funding for each center is contingent 
on successful contract negotiations with 
the Semiconductor Research Corp., 
Sematech’s agent for the project. 
Sematech said each center would receive 
from $500,000 to $1.5 million a year. 

The UC/Stanford proposal offered 


first-year funding of $250,000 from UC 
and $125,000 from Stanford—with the 
universities contributing up to $375,000 
a year thereafter—and requested fund¬ 
ing from Sematech of $1.9 million a 
year for five years. 

The theme of the center, according to 
the proposal, addresses “one of the 
most critical issues” governing the abil¬ 
ity of the US to compete in the semicon¬ 
ductor industry—lithography, the 
technology for production of extremely 
fine patterns on silicon wafers for the 
manufacture of integrated circuits. 

The proposal names UC Berkeley as 
contractor to the other university sites. 
At the two UC campuses and Stanford, 


The National Science Foundation has 
established the first research program 
designed to bring students and the disa¬ 
bled together to create new inventions. 

Through the Undergraduate Bioen¬ 
gineering Design Projects, young 
engineering students and disabled 
individuals will soon be cooperating in a 
community-centered program expected 
to boost the careers of the students, cre¬ 
ate new contacts between universities 
and their surrounding communities, 
and provide new or modified prototype 
equipment and special computer soft¬ 
ware for the physically and mentally 
disabled. 

Through this collaboration, disabled 
persons whose needs have long been 
unmet by commercially available tech¬ 
nology may soon enjoy improved edu¬ 
cational opportunities and greater 
freedom of movement. 

Senior scientists in engineering 
departments at 15 universities will each 
administer at least 10 of the research 
projects each year. 


research will be directed by key faculty 
members aided by other faculty investi¬ 
gators and selected graduate students 
and postdoctoral scholars. 

According to the proposal, technol¬ 
ogy transfer, or the passing of research 
results from the universities to industry, 
would take several forms: visitor 
exchanges and hands-on training; topi¬ 
cal workshops, reports and publica¬ 
tions; and the early release of software 
developed at the center. 

Additional technology transfer would 
occur as students who participate in the 
center’s research enter the work force 
and apply their special knowledge and 
training. 


The institutions are the Louisiana 
State University Medical Center at 
Shreveport, Montana State University, 
New Mexico State University, North 
Dakota State University, Rensselaer 
Polytechnic Institute, Southeastern 
Massachusetts University, Texas A&M 
University, Texas Tech University, 
Tulane University, the University of 
Akron, the University of Delaware, the 
University of Florida, the University of 
Houston, the University of Illinois at 
Urbana, and the University of Wash¬ 
ington. 

The NSF has awarded some $379,000 
to the universities for the first two years 
of the program. 

Under the program, engineering 
faculty will work with administrators at 
institutions that provide care or educa¬ 
tion to the disabled to identify needed 
projects for which no other source of 
funding is available. The engineers will 
then choose students who will carry out 
the research. 


NSF grants to support undergraduate 
engineering research by the disabled 
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Stanford researchers use laser process to produce superconducting fibers 


Using a laser, Stanford University 
researchers have produced supercon¬ 
ducting fibers capable of carrying large 
quantities of electrical current. This 
advance is being called a step toward 
the commercial realization of these 
superconducting materials. 

Funded by the National Science 
Foundation, the research was reported 
by Robert S. Feigelson, a Stanford 
research professor in the Materials 
Science and Engineering Department 
and director of the Crystal Science 
Department in the Center for Materials 
Research. He presented the report at a 
May superconducting conference hosted 
by Rutgers University. 

Coauthors were Don Gazit, visiting 
scholar from Israel’s Nuclear Research 
Center; David K. Fork, Stanford 
applied-physics graduate student; and 
Theodore H. Geballe, professor of 
applied physics and director of the 
Stanford Center for Materials 
Research. 

The research provides a model system 
for producing superconductors as short 
wires, which are useful prototypes for 
studying the properties of materials that 
will be needed for building magnets and 
other large devices. It also supplies an 
important technique for studying the 
composition and structure of supercon¬ 
ducting crystals. 

The very clean, tightly focused laser 
heat source permitted steady-state, 
rapid, continuous production, with no 
special containers or furnaces, Feigel¬ 
son said. 

The researchers used the laser-heated 
pedestal growth method to produce 
their prototype wire. They found the 
superconducting wire carried more than 


30,000 amperes of electricity per square 
centimeter at 4 degrees Kelvin before a 
contact failed and the sample was 
destroyed. The wire was made from a 
combination of bismuth, calcium, 
strontium, copper, and oxygen. 

The researchers noted that the LHPG 
method is a powerful means of rapidly 
growing small-diameter single crystals, 
especially oxides, both for fiber devices 
and physical-property studies. The crys¬ 
tals can have a diameter smaller than a 
human hair. 


One advantage of this method is that 
an advanced knowledge of the actual 
melt composition is not needed to pro¬ 
duce the appropriate, steady-state 
growth conditions. The melt automati¬ 
cally adjusts itself to the precise compo¬ 
sition needed. 

“There is evidence that fiber single 
crystals can be the most perfect crystals 
grown by any means,” the researchers 
said. Feigelson added that the technol¬ 
ogy “appears to have very broad 
applicability.” 


Test sites named for new Air Force technology 


New software development technolo¬ 
gies developed by the US Air Force will 
be available to researchers and business¬ 
men through a new program sponsored 
by the USAF Rome Air Development 
Center. 

Knowledge-Based Software Assistant 
(KBSA) Technology Transfer Consor¬ 
tium members selected as alpha test 
sites are Arthur Anderson and Com¬ 
pany, Boeing Computer Services, Lock¬ 
heed Missiles and Space, Martin 
Marietta Information and Communica¬ 
tions Systems, McDonnell Douglas 
Astronautics Operations, Reasoning 
Systems, the Rochester Institute of 
Technology, Software Productivity 
Solutions, Texas A&M University, and 
Texas Instruments. 

KBSA uses artificial intelligence to 
reduce software development costs and 
enhance product reliability. 


As alpha test sites, the selected labs 
will have access to KBSA interim 
products, early prototypes, and 
developers for training and consulta¬ 
tion, and will be able to evaluate the 
technology and integrate it into activi¬ 
ties where applicable. 

The Knowledge Based Systems 
Laboratory, which is part of the 
Department of Industrial Engineering, 
and the Laboratory for Software 
Research, which is part of the Depart¬ 
ment of Computer Science, have been 
selected as the joint alpha test site at 
Texas A&M. 

“Developers,” said Paula Mayer, the 
Texas A&M representative to the con¬ 
sortium, “need objective evaluations of 
KBSA products and need to be aware of 
the demands of potential users. Users 
need to be educated in the new technol¬ 
ogy as it becomes available.” 


Caltech students win Race for Space Software Chase 


A team of three Caltech undergradu¬ 
ates won the grand prize in the Race for 
Space Software Chase, an event 
cosponsored by the Smithsonian Insti¬ 
tute’s National Air and Space Museum 
(NASM) and Apple Computer. 

The winning program was designed 
by juniors Pierce T. Wetter III and 
Glenn C. Smith and sophomore 
Michael Meckler. Wetter developed the 
basic concept and designed the pro¬ 
gram’s simulation sections; Smith 
designed the color graphics; and Meck¬ 
ler designed and implemented the user 
interface. 


The contest’s goal was to develop an 
interactive software program using a 
Macintosh II computer to “demon¬ 
strate how computers can give wings to 
aeronautical ideas that otherwise might 
not get off the ground.” 

The Caltech program, which will go 
on display in NASM’s new Aerospace 
and Computing Gallery in 1989, lets the 
person playing with it design a rocket 
and launch it into space. The designer 
may choose rockets with one to five 
stages, opt for either liquid or solid fuel 
for each stage, and determine how 
much thrust each stage should carry. 


The simulated rocket then takes off, 
and the program computes the height it 
would have reached. 

Congratulating the winning team, 
Caltech President Thomas E. Everhart 
said the program gives “a real sense of 
how aeronautical engineers use com¬ 
puters to design spacecraft.” 

Wetter, the team’s captain, won a 
$5,000 internship this summer at the 
NASM, while he, Smith, and Meckler 
each received a Macintosh II. In addi¬ 
tion, Caltech will get seven of the per¬ 
sonal computers for its laboratory. 
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A new culture—32-bit technology on your desk 


Bill Gleason 

Virtually every business-oriented pub¬ 
lication has run an article on the new 
Intel 80386-based PCs. Their advanced 
features and speed have made them the 
darlings of programmers and the PC 
publishing community. They have 
“long legs,” running at clock speeds of 
16 and 20 MHz. They can control data 
four bytes at a time. We are told that 
OS/2 will deliver “a new level of func¬ 
tionality to the personal computer. 

OS/2 isn’t system software, it’s a whole 
new culture.” The 386 with OS/2 will, 
in short, demonstrate speed, power, 
and another quantum leap forward for 
the computer industry. These features 
by and large result from the 80386 
microchip’s capabilities. 

The main engine of a personal com¬ 
puter is, of course, its microprocessor. 
The heart of the microprocessor is its 
registers, where the actual computations 
take place. Previous microprocessors 
have used 16-bit registers. The eight 
registers of the 80386 are double that 
width, so they can work with twice the 
information in the same time. In addi¬ 
tion, these registers can function as 
pairs of 16-bit registers to provide com¬ 
patibility with the command structure 
of earlier processors. Further, four of 
the 80386 registers can be manipulated 
eight bits at a time, taking compatibility 
down to the base level. 

Besides a 32-bit data path, the 80386 
has 32 bits of addressing, so it can 
directly manipulate 2 32 bytes of memory 
—a total of four gigabytes. It is 
designed to swap bytes from RAM to 
disk to make programs think it has 
more RAM at its disposal than really 
exists, a feature known as virtual mem¬ 
ory. Many internal features facilitate 
multitasking operations, including four 
levels of privilege, privileged instruc¬ 
tions, a system of access rights, and the 
ability to segment tasks. The instruction 
set of the 80386 is a superset of the 
80286, so older code will run on the new 
chip with no problems. 

The 80386 chip, developed and 
manufactured by Intel, is the company’s 


first product to operate with large, con¬ 
tiguous fields of data. It also has the 
capability to slice itself up into multiple 
8086 sessions. On the one hand, its 
architecture duplicates today’s mini- 
and mainframe computers. On the 
other hand, it can duplicate the efforts 
of several ordinary PCs all running in 
one box simultaneously. 

The performance of the 386 chip— 
three to four million instructions per 
second (or MIPS)—puts computers 
based on it in the same class as the 
larger VAX minicomputers. That’s 
power enough for computer-aided 
design, desktop publishing, and statisti¬ 
cal analysis, all sitting right there on top 
of your desk—very attractive in today’s 
cost-conscious business environment. 

Unfortunately, the promise of the 
80386 CPU lies largely in the future. 
Very little software written at this 
moment taps 32-bit technology on a 
PC. The crux of the problem is in the 
operating system. DOS uses the 16-bit 
instruction set of the 8088, 8086, and 
80286. When the 80386 confronts 16-bit 
instructions, it operates just like one of 
the earlier chips, matching the AT or 
80286 instruction for instruction. 

New software utilizing the full capa¬ 
bility of the 80386 as well as OS/2 fea¬ 
tures is on the drawing board and will 
be available within the next year. 
OS/2-compatible dBase IV, for exam¬ 
ple, is targeted for release in mid-1988. 

I believe that during 1988 we will see a 
proliferation of minicomputer applica¬ 
tions transitioning to the PC. We will 
also see many new applications particu¬ 
larly in local area network software and 
analytical programs that accommodate 
32-bit technology. 


The Fivestar FS386 

With all of the preceding facts in 
mind, let’s proceed through an evalua¬ 
tion of a 386 personal computer from 
Fivestar Computers, a Dallas, Texas, 


mail-order firm. Four considerations— 
performance, price, compatibility, and 
future software—will form the basis of 
the following evaluation on the Fivestar 
FS386/16 CPU. 

This review will focus on the utility of 
the FS386, without getting all twisted 
up in performance testing other than 
the benchmark tests that follow to give 
you a relative feel for processing speed. 
Utility as defined in this review simply 
means the ability to operate the com¬ 
puter efficiently and with a minimum 
number of hassles. Typically, you 
would like to think that you could 
accomplish the transition from your 
current machine to this new, more 
powerful PC without having to unlearn 
an unreasonable number of responses 
built up over the years of using a per¬ 
sonal computer. Further, it would be 
nice to transfer those applications you 
use on a day-to-day basis without hav¬ 
ing to build elaborate transfer routines 
because of the differences in DOS or 
idiosyncrasies of the existing software 
you have in your library. Finally, all of 
us would like to have hardware and PC- 
control software forgiving enough not 
to wipe out a full day’s work when we 
don’t back up our data quite as often as 
we should. 

System configuration. The Fivestar 
FS386 is an IBM PC AT-compatible 
microcomputer board-set with the speed 
of the 80386 microprocessor. The CPU 
measures 16K inches long and 21X 
inches wide. It consists of a CPU board 
and an attached memory module. Mem¬ 
ory modules come in two- and eight- 
megabyte versions. The CPU is “bus- 
based,” meaning the system backplane 
contains expansion slots and a power 
supply instead of a motherboard. The 
386 CPU plugs into the bus along with 
expansion boards. According to 
Fivestar, bus-based systems have the 
advantage of being more easily 
upgraded and easier to work on than 
systems that use motherboards. 

Fivestar also provides an upgrade for 
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the FS286 system, making it into a 386 
machine. Or, I could make this 386 
computer into a 286 computer by sim¬ 
ply replacing the CPU board. The 
upgrade to a 386 costs approximately 
$1,600. 

The FS386 operates at a 16-MHz 
clock speed, but using software com¬ 
mands you can slow it to either 6 MHz 
or 5.3 MHz to accommodate software 
with timing-dependent loops or copy¬ 
protection schemes. 

The 80386 microprocessor can 
address up to four gigabytes of mem¬ 
ory. It has an even larger virtual- 
address space, as well as full multiuser 
and multitasking capabilities. 

The FS386/16 personal computer I 
reviewed came with 2 Mbytes of RAM, 
serial/parallel ports, a 1.2-Mbyte 
floppy disk drive, a 45-Mbyte Priam 
hard disk drive, a Tatung EGA color 
monitor with a green/amber switch, an 
enhanced 101-key keyboard, a Fivestar 
EGA card with 640 x 480 resolution, 
and MS-DOS 3.3. The invoice cost for 
the machine described was $3,995. 

The system arrived three days after it 
was shipped from Carrollton, Texas, a 
suburb of Dallas. It came in two boxes 
heavily insulated against damage, one 
for the computer and keyboard and one 
for the monitor. I had the computer up 
and running fifteen minutes after I 
removed it from the box. The company 
installed DOS 3.3 and Priam support 
software on the C drive at the factory, 
which made startup absolutely painless. 

Informative installation and opera¬ 
tion manuals for the FS386, Priam 
Hard Drive, and EGA monitor came in 
the box. The Priam User Manual is 
quite complete and features special sec¬ 
tions on installing Novell Netware and 
sharing the drive with DOS and Xenix. 
In addition, a skimpy 24-page opera¬ 
tions manual for the FS386 contains 
installation procedures for the CPU, a 
functional overview of the CPU, and 
information on the connector interface. 


Keyboard layout. The enhanced 
101-key keyboard by KeyTronics has 
the standard typewriter-style keyboard 
with locators on the “J” and “F” keys 
to assure proper positioning of your 
fingers. The function keys (1 through 
12) are arranged across the top. The Esc 
key is in the upper-left corner. A dual set 
of Insert, Delete, Home, End, Page Up, 
and Page Down keys sit just to the right 
of the typewriter keyboard, with four 
cursor keys just below. A calculator 
number pad lies to the right of the cur¬ 
sor keys. 

This is a functional arrangement, 
once you retrain your fingers. The keys 


feel a little stiff, requiring a positive 
stroke to get the desired.results. 

Quality control. You can remove the 
cover by removing four screws and slid¬ 
ing the cover forward. There is, of 
course, no motherboard on the bottom 
of the chassis. Instead, it is mounted on 
a slotcard. Six short and six full-sized 
slots accept additional cards. Six 
peripheral-drive slots accept additional 
disk drives. The power harness contains 
four power plugs, daisy chained to 
allow additional drive hookup. 

The chassis is laid out uniformly and 
neatly with abundant cable clamps to 
support electrical harnesses. An inspec¬ 
tion of the solder joints on the boards 
revealed even flow on the pads, with no 
voids. The boards are not overpopu¬ 
lated with components. 

All in all, the nicely appointed chassis 
gives the impression of being well 
thought out. The excellent workman¬ 
ship paid attention to proper wire¬ 
routing techniques and component 
installation. 

Warranty and user support. Fivestar 
performs a 48-hour burn-in prior to 
shipment. Each system is covered by a 
30-day return policy and a one-year 
limited warranty on parts and labor. 
Annual on-site service is offered for 
“less than a dollar a day” by a service 
company called Momentum, a 20-year- 
old company with 150 locations nation¬ 
wide. In addition, Fivestar maintains a 
staff of technicians to bail you out 
when things get just a bit snarled. A 
toll-free number is provided. 


Features of the FS386 

• Incorporates all features found 
on the IBM PC AT system board, 
including the interrupt con¬ 
trollers, keyboard controller, DMA 
controllers, real-time clock, and 
CMOS RAM. 

• 16-MHz, 32-bit iAPX 386 proces¬ 
sor for higher throughput and 
processing speeds. 

• Piggyback 32-bit-wide memory 
modules for RAM expansion up 
to 16 Mbytes. 

• Interleaved page-access scheme 
that achieves higher perfor- 


Coprocessor support. The FS386 sup¬ 
ports both the 80287 and the 80387 
chips. You can adjust the clock speed of 
the 80287 to 5 MHz, 5.7 MHz, 8 MHz, 
or 10 MHz to permit maximum perfor¬ 
mance of the versions now available. 
You can set the clock speed of the 
80387 at either 16 MHz or 20 MHz. 

Performance. System performance 
seemed comparable to other 80386 
machines. Using the PC Magazine 
Benchmark Series Processor Speed 
Instruction Mix Test, the FS386 ran 
about 10 percent slower than the 
16-MHz Compaq 386 and twice as fast 
as an 80286 system. See Table 1 for a 
comparison. 

Doing a cost-to-capability compari¬ 
son reveals that, although slower than 
the PC-Limited offering, the FS386 
runs the Instruction Mix test at a speed 
comparable to the Compaq 386 and 
costs $3,000 less. 

Compatibility. The machine’s ability 
to load and run without a hassle the 
software I use frequently was the 
criteria I used for the next series of 
tests. I installed Lotus 1-2-3, dBase III 
Plus, Open Plan Project Management, 
Pro Design II, and Word software on 
the 40-Mbyte hard drive. Each loaded 
easily and operated immediately after 
installation. I perceived differences in 
the speeds at which the software oper¬ 
ated. To quantify my perceptions of 
quickness, I analyzed a large database. 
The analysis took eight minutes on an 
IBM PC AT and four minutes on the 
FS386. Other software also ran faster 


mance than possible using con¬ 
ventional DRAM arrays. 

• Dynamic clock-switching from 16 
MHz to 6 MHz or 5.3 MHz accom¬ 
modates software with timing- 
dependent loops or copy¬ 
protection schemes. 

• Compatible with all existing soft¬ 
ware and hardware for the IBM 
PC AT. 

• Built-in serial and parallel ports. 

• Optional 80387 or 80287 numeric 
data processor can run at its full¬ 
rated frequencies. 
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Table 1. Price and performance comparison. System configuration: 386 CPU with 16-MHz processing speed, 101-key 
enhanced keyboard, one-megabyte RAM, 1.2-Mbyte floppy disk, 40-Mbyte hard disk. 



Fivestar 

FS386 

Pc Limited 
386-16* 

Kaypro 

386* 

IBM 

PS/2, Model 80* 

Compaq 
Deskpro 386* 

Price: 

$3,995 

$4,995 

$6,715 

$6,995 

$7,897 

Performance: 

(seconds) 

Instruction Mix 

4.39 

3.57 

4.02 

4.39 

4.01 

NOP 

2.14 

2.15 

2.15 

2.09 

2.09 

Conventional 

Memory 

.77 

.44 

.85 

.63 

.77 


* Source: PC Magazine, Sept. 29, 1987 

Instruction Mix—measures the time it takes to execute a selected series of processor-intensive tasks. 

NOP—measures raw clock-speed and memory-access time. 

Conventional Memory—allocates 256 Kbytes of conventional memory and treats it as a series of 64-byte records. 


on the FS386, but I did not measure the 
speeds. 

Future software. OS/2, promised for 
the 80286 application, is still not avail¬ 
able. This operating system is the key to 
future development for 32-bit applica¬ 
tions. However, already available 16-bit 
multitasking operating systems at 16 
MHz allow one to use several current 
software packages concurrently. Three 
software packages on your dealer’s 
shelf or obtainable through mail-order 
houses are DESQview from Quarter¬ 
deck Office Systems, Concurrent DOS 
386 from Digital Research, and PC 
MOS/386 from The Software Link. In 
the wings lurk Microsoft Windows/386, 
Microport Unix System V.3/386 run¬ 


ning DOS Merge 386, and The Santa 
Cruz Operation Xenix running V/P/ix. 
All do DOS applications and all take 
advantage of the virtual 8086-mode 
feature. 

Recommendations 

Is the 80386-based PC a good invest¬ 
ment now, or would waiting for soft¬ 
ware production and prices to settle 
down be a better strategy? Certainly, 
the performance/cost comparison 
showed that the Fivestar FS386 falls 
into an affordable price range. Testing 
showed the FS386 to be fast and com¬ 
patible with existing software. It is relia¬ 
ble and well constructed. The only rub 


seems to be the unavailability of soft¬ 
ware exploiting the 32-bit chip. This dis¬ 
advantage is to some degree offset by 
the availability of 16-bit multitasking 
software. Need, of course, is the real¬ 
time driver. If your current hardware 
complement just isn’t cutting it because 
of growth, or if you are about to make 
a investment in new hardware, it would 
be prudent to consider a 80386 CPU. 

Overall, I believe that the Fivestar 
FS386 is a good buy today. It is cer¬ 
tainly a pleasure to use. Although today 
the benefits of the 80386 are primarily 
speed and utility, tomorrow it will 
definitely change the personal computer 
and how you use it. 

Reader Service 20 


Want an inexpensive and complete 386 system? 
Build it yourself! 


Frank Pappas, Intermetrics 

Thinking of moving to an 80386- 
based system? Then you’re probably 
planning to buy an assembled system. 
But you might first want to consider 
two do-it-yourself approaches. One 
approach is to get Heath-Zenith’s 
H-386 kit and put your own system to¬ 
gether. The second approach is to up¬ 
grade your IBM PC AT system (80286- 
based) to a 386 system using Intel’s 
Inboard 386/AT. Both approaches offer 
significant advantages over buying an 
assembled 386 system. In addition, I’ll 
cover add-in peripherals and supporting 
software to make your system complete. 

In approaching this review, I thought 


it would be interesting to find out what 
advantages, other than just speed, a 
386-based system could provide. I 
decided to build a system that could 
support communications and graphics, 
as well as the typical word processing 
and Ada compilations that I commonly 
use on a PC. I also wanted to take 
advantage of the 386 architecture and 
do several things at once. (Multitasking 
operating environments will let me do 
this, but they will be the subject of a 
future column.) 

Finally, since the flavor of this review 
was already do-it-yourself, I decided to 
take a do-it-yourself approach to install¬ 


ing the additional hardware I needed to 
support such a system. Other than the 
H-386, which has a fixed price, many of 
the hardware prices that I quote in this 
review are typical of what you would 
find in an ad placed in a PC magazine 
by a mail-order house. I had two rea¬ 
sons for doing this. One reason is that, 
in some cases, you cannot order the 
hardware component directly from the 
manufacturer. The other reason is that, 
even if you can order the hardware 
component directly from the manufac¬ 
turer, why spend more? Anyway, when 
I do quote a typical mail-order price, 

I’ll make that clear. 
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Heath H-386 

It’s easy to like the H-386. Assem¬ 
bling the kit is both easy and fun to do. 
Moreover, the assembled H-386 is an 
impressive and well-thought-out 
system—essentially a kit version of the 
Zenith Data Systems (ZDS) Z-386. 

The H-386 kit comes well equipped. 

It has a 5.25-inch 1.2-Mbyte floppy 
drive and hard disk controller. The 

31- KHz video card automatically 
switches between EGA and CGA, or 
MDA and Hercules, depending on the 
software used. The one-megabyte, 

32- bit dynamic RAM expands to 16 
Mbytes. In addition to the two I/O 
ports—one serial and one parallel—and 
the 101-key keyboard, the H-386 comes 
with Heath-Zenith’s MS-DOS 3.21, 
diagnostics software, and a software 
package called Integrated 7 + (spread¬ 
sheet, word processor, relational data¬ 
base, communications software). The 
$3,349.95 price tag for this kit seems 
pretty reasonable, even though a moni¬ 
tor is not included. 

The system I evaluated also had a 
10-MHz 80287 math coprocessor 
($525), a 4-Mbyte dynamic RAM card 
($2,199), and a 40-Mbyte Control Data 
hard disk drive with 28-ms average 
access time ($1,699). I also upgraded to 
Zenith’s Z-449 VGA card ($599). Since 
the kit does not include a monitor, I 
used Zenith’s ZCM-1490 RGB analog 
monitor ($1,000). This brings the price 
of the system up to about $8,400. An 
80387 math coprocessor is available for 
$1,199. 

The add-on features, other than the 
monitor, seem considerably overpriced. 
You could do much better buying these 
add-ons from an independent distribu¬ 
tor and installing them yourself. For 
example, in one PC magazine I found 
the 10-MHz 80287 for $319 and the 
16-MHz (20-MHz) 80387 for $499 
($749). Even if you needed a 20-MHz 
80387, with the money you could save, 
you could get a pretty nice monitor that 
would support your EGA/VGA graphics. 

I didn’t look at alternatives to com¬ 
puter memory. I’ll explain why later. 
VGA cards and hard drives, which I did 
look at, are covered under separate 
headings. 


Assembly. As I said before, building 
the H-386 was easy, but it took me 
about 14 hours rather than the two 
evenings Heath claims it should. I spent 
most of the extra time matching up and 
labeling incorrectly marked parts. For¬ 
tunately, the parts list had drawings of 
all the parts. 

The rest of the installation went well. 


Heath-Zenith H-386 kit 

Each step is carefully spelled out and 
includes detailed figures to help you 
understand what you are supposed to 
do. A few minor things made no sense, 
so I just ignored them. The system still 
came out working fine. 

The system came in several boxes. 

The kit was shipped in a huge box that 
was difficult to pick up. The 4-Mbyte 
memory board was shipped separately, 
as were the hard disk and the 80287. 

The one disadvantage with the packing 
is that you don’t get a reasonable box to 
use if you ever need to pack up and 
move the assembled system. The moni¬ 
tor also came in a separate box. 

The main components of the kit are a 
chassis and cover, a backplane, a power 
supply, a fan, a lock mechanism, a 
floppy-disk-drive assembly with drive 
chassis, several plug-in boards, and a 
keyboard. Included is the necessary 
hardware to put the components 
together. Several finishing pieces make 
the assembled computer look like a 
professionally assembled system. 

Experienced computer users shouldn’t 
have any trouble putting the H-386 
together. If you do, you can call for 
assistance. However, the telephone 
number supplied is not an 800 number 
and is manned only during normal 
working hours. 


The backplane approach used by 
Heath-Zenith makes the H-386 especially 
interesting. The backplane is only about 
half the normal size of a standard 
motherboard. This is possible because 
only the expansion slots, the clock/ 
calendar, the battery backup, the 
CMOS RAM used to hold the configu¬ 
ration information, and the keyboard 
connector are actually on the back¬ 
plane. Everything else plugs into one of 
the expansion slots. 

There are two PC XT 8-bit-compatible 
slots, two PC AT 16-bit-compatible 
slots, and six ZDS custom 386 32-bit 
slots. The 80386 and the math coproces¬ 
sor are both on the CPU card that plugs 
into one of the 386 slots. The I/O card 
and system memory card (one megabyte 
in the kit) also plug into 32-bit slots. 

The disk controller card plugs into a 
16-bit slot, and the video card plugs 
into an 8-bit slot. This leaves one XT 
slot, one AT slot, and three 386 slots 
for expansion. 

Memory. In the system I evaluated, 
another 386 slot was taken up by a 
4-Mbyte memory board. A total of four 
memory boards, each with 4 Mbytes, 
can be placed in the system. If you are 
willing to give up one of the 386 slots, 
you can add a 64-Kbyte static RAM 
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system-cache board ($599) to speed up 
the system. The cache board did not 
come with my evaluation unit. 

According to Heath technical sup¬ 
port, if another manufacturer makes a 
32-bit memory board, it probably will 
not work in the H-386 because the slot 
is a ZDS custom slot. A 16-bit memory 
board would work, but much slower. 

The standard configuration for ZDS 
memory boards is for extended mem¬ 
ory. However, each board can be 
separately configured to supply part of 
its memory as EMS memory compatible 
with the Lotus/Intel/Microsoft 
Expanded Memory Device Interface 
Specification. On a 4-Mbyte board, you 
can configure 2-Mbytes as expanded 
memory. On a one-megabyte board, 
you can configure the full memory as 
either extended memory or expanded 
memory. On the system memory board, 
you can select either 512 Kbytes or 640 
Kbytes as system memory, with the 
remaining memory configured as either 
extended memory or expanded memory. 

The monitor program. The H-386 has 
a really nice built-in monitor program. 
First of all, you use the monitor to per¬ 
form system setup. It also provides 
some built-in diagnostic tests and many 
debugging features. Finally, the moni¬ 
tor gives you control over how the sys¬ 
tem should boot up. You can select the 
standard floppy-then-hard-drive 
approach, or just have it always boot 
from the first hard drive. Even better, 
you can have the monitor activate when 
you boot the system, so that you can 
select the drive and partition you want 
to boot from. In particular, if you have 
both DOS and Xenix on your system, 
you can select a DOS-bootable partition 
or a Xenix-bootable partition. 

At the highest speed, the CPU nor¬ 
mally runs with zero wait states. If you 
need to, however, you can adjust the 
system to run with one wait state, using 
software or setting it in the monitor. 

The technical documentation claims 
that with software you can select more 
than one wait state, but I could not fig¬ 
ure out how to do this and neither could 
customer hardware support. 

The analog monitor. The ZCM-1490 
analog monitor is really impressive. 

This high-resolution monitor uses 
Zenith’s new Flat Technology CRT. 

The first thing that impressed me was 
the sharpness of the picture and the lack 
of noticeable distortion. Normally, I get 
eye strain from looking at a monitor for 
a long period of time, but not with the 
glare-free screen of the ZCM-1490. Ini¬ 
tially, I had a slight illusion that the 


screen was convex, but I didn’t notice 
this for long. 

Why is a flat screen better? Well, a 
color CRT has three phosphors—red, 
blue, and green—coating the inside face 
of the display screen. To produce an 
image, an electron beam inside the CRT 
strikes the phosphors. A perforated 
metal screen, called a shadow mask, is 
stretched in front of the phosphor to 
ensure that the electron beam only 
illuminates a specific area of the screen 
and specific color phosphors at a spe¬ 
cific time. 

In a conventional CRT, the shadow 
mask is curved. According to ZDS, as 
the shadow mask heats up, its shape 
distorts, which leads to image distortion 
and lack of sharpness. In the Flat Tech¬ 
nology CRT, the shadow mask is 
stretched flat and held under extreme 
tension. This prevents the shadow mask 
from losing its shape when heated up. 


The documentation and 
technical support for the 
H-386 are outstanding. 


The ZCM-1490 can display informa¬ 
tion in EGA, CGA, MDA, Hercules, 
VGA, and MCGA modes when used 
with a video card that produces an RGB 
analog signal with a constant 31.49 kHz 
horizontal scan frequency. The monitor 
will automatically adjust the display 
height to accommodate 350-, 400-, or 
480-line video modes. Also, use of an 
analog signal permits the display of an 
unlimited number of colors. 

To really appreciate the ZCM-1490, 
you have to see it yourself. It works 
well with the EGA video card supplied 
with the H-386 and even better with the 
Z-449 VGA video card. If you’re look¬ 
ing for a high-resolution analog color 
monitor—even for a PS/2—make sure 
you see this one. 

Special features and software. Several 
features of the H-386 pleasantly sur¬ 
prised me. The battery on the backplane 
is an AA battery, which is much easier 
and cheaper to replace than a standard 
AT battery. The backplane also has 
LEDs that monitor power supplies. Six 
LEDs on the I/O card aid diagnostics, 
each LED representing a major system 
component. When you first turn on the 
system, the six LEDs all light up. As 
each system component checks out suc¬ 
cessfully, its LED goes out. If a check 
fails, the system halts without turning 
off the LED, so you know which com¬ 
ponent failed. 


Heath-Zenith MS-DOS 3.21 is sup¬ 
posedly Zenith’s version of Microsoft’s 
MS-DOS 3.3 release. Since I haven’t 
seen MS-DOS 3.3,1 don’t know if this 
is true, but it sure is better than the PC- 
DOS 3.2 I’m using on my AT clone. 

One of the most notable features of ver¬ 
sion 3.2 is the hard disk support. Fdisk 
is finally gone! In its place are several, 
much easier to use, programs. And if 
you have a hard disk with capacity 
greater than the DOS 32-Mbyte parti¬ 
tion limit, you can divide it into multi¬ 
ple accessible partitions without using 
third-party drivers. The Asgnpart com¬ 
mand accomplishes this, letting you 
assign a logical drive name to a par¬ 
tition. 

Documentation.The technical 
documentation that comes with the 
H-386 is outstanding. You get several 
thin manuals: Video Drivers Installa¬ 
tion Guide, Disk Based Diagnostics, 
and Owner’s Manual. The Service Man¬ 
ual includes much of the information 
already in the detailed assembly instruc¬ 
tion guide, but in a more compact man¬ 
ual. I didn’t get a copy of the Service 
Guide, containing circuit diagrams and 
whatever, because it was out of stock. 

These manuals contain a lot of useful 
information, but they pale in compari¬ 
son to the Technical Reference Manual. 
This manual, which is thicker than the 
MS-DOS reference manual, contains 
just about anything you could want to 
know about the H-386. The few things 
not included probably appear in one of 
the other manuals. Every major piece of 
the H-386 is covered in detail. If the 
documentation provided with the H-386 
served as the standard for comparison 
with documentation provided by other 
systems, the H-386 might well be in a 
class by itself! 

Support. As if the documentation 
weren’t enough, the hardware technical 
support is outstanding. I called several 
times to check out the service and was 
pleased each time. As I mentioned 
before, only the question about multi¬ 
ple wait states went unanswered. A 
bulletin board service is also provided. 

The only support problem might be 
with software. While hardware support 
can help with MS-DOS problems, all 
other software support is handled by 
local Heath-Zenith stores. I had a prob¬ 
lem with Windows 386, so I had to call 
my local Heath-Zenith dealer. Unfor¬ 
tunately, no one there knew anything 
about Windows 386, so they wanted me 
to bring in the software and show them 
the problem. To me that’s just a waste 
of my time. As it turned out, Zenith’s 
hardware support happened to know 
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that Zenith has its own Windows 386 
version. Unfortunately, I didn’t get a 
copy in time for this review. 

Recommendations. To sum up, I 
think the H-386 kit is a good buy. By 
putting together your own 386 system, 
you pay only about half of what you 
would for a comparable IBM system. 

At the same time, you get a system that 
you can service and enhance yourself. 
And if you ever need any help, it’s just 
a phone call away. 

Reader Service 21 


Intel Inboard 386/AT 

Moving to a 386-based system can 
include some hidden costs if you 
already have a loaded PC AT. Do you 
have to lose your investment? Or maybe 
you need the power of a 386, but just 
can’t afford to upgrade from your AT. 
Are you stuck with a 286-based system? 
Thanks to Intel’s Inboard 386/AT, the 
answer to both questions is no. 

Installation in general. With the 
Inboard, you can change your AT into 
a powerful 386-based system. You just 
plug the Inboard into one of your AT’s 
16-bit slots, pull out your 80286 chip, 
and connect the Inboard to the vacated 
80286 socket with the supplied cable. 

If you have an AT clone, don’t just 
rush out and buy an Inboard. Intel will 
guarantee the Inboard to work in only a 
few clones: the Compaq Deskpro 286 (8 
MHz), the Compaq Portable 286 and 
II, the Tandy 3000HD and HL, and the 
WysePC 286. Intel has successfully 
checked out these clones. The installa¬ 
tion manual devoted a separate chapter 
to each manufacturer’s computer. 
Nonetheless, the Inboard may well 
work in other clones—it worked in my 
no-name Korean clone—but Intel will 
not guarantee it. 

Compatibility and upgrading. Intel’s 
technical support staff will answer your 
questions about compatibility. If you 
do contact Intel, you will find a staff 
both pleasant and knowledgeable. I 
found the staff to be one of the nicest 
that I’ve worked with, especially the 
manager of the public relations 
department. 

According to Intel literature, about 
four million AT owners could use the 
Inboard to move up to a 386-level sys¬ 
tem. For these AT owners, the Inboard 
is a viable option. I found it advertised 
for $949, plus $139 for the installation 
kit. 


Keep in mind that this is just an 
upgrade option. Don’t go out and buy 
an AT and an Inboard, thinking it a 
cheap way to get a 386-based system. If 
you need an additional system, buy a 
386 clone. 

For XT owners, an Inboard/PC lets 
you upgrade your XT to a 386-based 
system. Since I did not review this prod¬ 
uct, I can’t tell you any more about it. 

Features. The standard Inboard 
386/AT comes with an 80386 processor 
and a 32-bit, 64-Kbyte static RAM 
cache. One socket will accept an 80387 
coprocessor. You can order the board 
with one megabyte of 120-ns, 32-bit 
dynamic RAM, advertised for $1,395, 
and an optional 2-Mbyte piggyback 
board, advertised for $2,290. 

Once operating in your system, you 
can run the Inboard at one of four 
software-selectable speeds, the fastest 
speed being 16 MHz. Data and instruc¬ 
tion fetches first check the 64-Kbit 
cache. According to Intel literature, the 
hit rate exceeds 90 percent. On a cache 
miss, either the (optional) 120-ns mem¬ 
ory on the Inboard card or the other 
memory in the system must be accessed. 
The Inboard memory is accessed at 16 
MHz with two wait states. The other 
memory is accessed at 16 MHz with 
eight wait states, which for an IBM AT 
would be at the standard 8-MHz bus 
speed. 

In addition to the Inboard, you also 
get an installation kit. The kit contains 


the special cable, the manual, software 
diskette, chip puller, and some other 
things you need for installation. You 
can order two types of cables. One 
cable type works in an IBM AT (and 
also happened to work in my clone), 
while the other cable type works with 
clones. You have to order the correct 
cable, or it won’t install in your 
computer. 

Installation and my configuration. 

For this review, I installed the Inboard 
386/AT with one megabyte onboard, a 
2-Mbyte piggyback board, and an 
80387 coprocessor. I already had a 
150-ns, 4-Mbyte extended memory 
board (from Profit Systems) installed in 
my machine. The first installation steps 
require you to plug the 80387 and the 
piggyback board into the Inboard. 

Once that’s completed, you can start on 
your AT. If you have a 6-MHz IBM 
AT, you need to replace the crystal. The 
replacement comes in the installation 
kit. 

The Inboard’s memory can supply 
conventional memory, but you may 
have to adjust your clone. Some clones 
may require you to disable their own 
conventional memory down to 256 
Kbytes through jumpers. Some of these 
clones may, however, require that they 
be populated with 640-Kbyte memory 
even though most of it will be disabled. 

An 80287 plug comes with the instal¬ 
lation kit. This plug must occupy the 
80287 coprocessor slot. If you have an 
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80287 chip installed, you must remove it 
and insert the plug. Intel warns that 
failure to do so may damage the 80287 
and the 80386 chips. If you have an 
80287 installed, this is the one loss you 
face when upgrading with the Inboard. 
You can place a coprocessor on the 
Inboard, but it must be an 80387. 

The 80287 chip must be removed 
next, possibly after moving a few jum¬ 
pers. The chip puller supplied in the 
installation kit makes this easy. Then 
you plug the cable into the 80286 
processor slot, install the Inboard into 
one of the 16-bit slots, and plug the 
cable into the Inboard. 

To install the Inboard kit, you will 
have to remove some cards from their 
expansion slots, possibly moving them 
to other slots. If you have an IBM AT 
with a hard disk, you will have to slide 
the drive out of your way during the 
installation. That’s the extent of the 
installation. Now that may seem com¬ 
plicated, but it really isn’t. The well- 
written installation manual takes you 
through the process step by step. 

Software. The Inboard comes with 
software that simplifies installation and 
use of the Inboard. One program that 
you should run before installing the 
Inboard helps you determine the switch 
settings for the Inboard. Another pro¬ 
gram that you run after installation 
helps you set up the software you need 
to get the most out of your Inboard. 

One of the supplied drivers, 
INBRDAT.SYS, is the key to several 
services useful to many Inboard users. 
With other software supplied by the 
company, typical services at your dis¬ 
posal include changing speed, using 
disk caching to speed up system perfor¬ 
mance, and using extended memory as 
expanded memory. 

My only complaint about the Inboard is 
the size (44 Kbytes) of the INBRDAT.SYS 
driver. I have a number of programs 
that require several buffers and files, so 
I need to minimize my use of conven¬ 
tional memory. I want just to run at 16 
MHz, and I don’t want to waste any 
conventional memory doing so. For¬ 
tunately, the installation manual 
explains how to change speeds in soft¬ 
ware. I wrote a simple Ada program to 
do this, so I don’t need to use the driver 
for most applications. 

Recommendations. After using the 
Inboard for some time now, I like it. If 
your AT can take the Inboard, then you 
might want to give serious consider¬ 
ation to buying an Inboard rather than 
buying an entire 386 system. Your sav¬ 
ings can be substantial. 
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Disk drives 

I considered three alternatives to the 
hard disk supplied by Heath-Zenith: a 
62-Mbyte drive from Priam, and 
40-Mbyte and 80-Mbyte drives from 
Seagate. Like the Heath-Zenith drive, 
these three drives use MFM encoding. 
That means you can use them with a 
standard AT controller board. Also, 
each has automatic parking, so you 
don’t need to park the heads when you 
turn off the system. 

Priam 62-Mbyte drive. I looked first 
at the Priam Interspace ID-62-AT-D2 
62-Mbyte internal hard disk drive. This 
full-height drive has an average access 
time of 23 ms and a mean time between 
failures of 40,000 hours. It has four 
disks, 1,018 cylinders, and five heads 
with 17 sectors per track, 512 bytes per 
sector, and a data-transfer rate of five 
megabits per second. Recently adver¬ 
tised in a PC magazine for $800, this 


Inboard software 
simplifies installation 
and use. 


drive offers a substantial savings over 
the one available from Heath-Zenith, is 
faster, and has 50 percent more storage 
capacity. 

The ID-62 came with substantial 
documentation, both technical and 
installation. Installation documentation 
is good enough to enable most com¬ 
puter owners to install the drive them¬ 
selves. The software provided with the 
ID-62 includes drivers to allow multiple 
DOS partitions and to allow partitions 
larger than the DOS 32-Mbyte limit. 
Special versions of Format and Fdisk 
deal with these additions. Since config¬ 
uration information for the drive is 
stored in the last six cylinders, you are 
warned against using the DOS Format 
and Fdisk commands. 
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Seagate 40-Mbyte and 80-Mbyte 
drives. The Seagate ST251-1 40-Mbyte 
drive has a 28-ms access time and a 
MTBF of 30,000 hours. It has three 
disks, 820 cylinders, and six heads with 
17 sectors per track, 512 bytes per sec¬ 
tor, and a data transfer rate of five 
megabits per second. This half-height 
drive was recently advertised in a PC 


magazine for $499, a drastic savings 
over the Heath-Zenith-supplied drive. 

The ST4096 80-Mbyte drive is a full- 
height drive with a 28-ms access time 
and a MTBF of 25,000 hours. It has 
five disks, 1,024 cylinders, and nine 
heads with 17 sectors per track, 512 
bytes per sector, and a data transfer 
rate of five megabits per second. This 
drive, which was recently advertised in a 
PC magazine for $869, offers compara¬ 
ble speed to the Heath-Zenith 40-Mbyte 
drive, at less than half the cost and dou¬ 
ble the storage capacity. 

The installation documentation for 
these drives might provide enough 
information for someone who has built 
the H-386 or feels comfortable working 
on the insides of a computer, but it 
probably isn’t good enough for the typi¬ 
cal computer owner. However, this 
shouldn’t keep you away from the 
Seagate drives because Peter Norton’s 
book (described below) will help you 
along. 

Seagate provides software to allow 
you to manage multiple DOS partitions 
and partitions larger than the DOS 
32-Mbyte limit. It also requires using a 
driver. 

If you have MS-DOS 3.3 or Heath- 
Zenith MS-DOS 3.2, you can get rid of 
the drivers, unless you want partitions 
larger than the DOS limit. If you don’t 
have one of these DOS versions, 
eliminating these drivers is alone a good 
reason to upgrade. Drivers served their 
purpose when DOS didn’t support mul¬ 
tiple partitions, but they did so by 
decreasing conventional memory avail¬ 
able to applications and slowing down 
disk accesses. 

ST251-1: Reader Service 24 
ST4096: Reader Service 25 

Recommendations. All three drives 
are more cost effective than the drive 
supplied by Heath-Zenith. The 
80-Mbyte ST4096 seems the best choice, 
with the 62-Mbyte ID-62 a good second 
choice. Of course, you give up some¬ 
thing by not getting your hard drive 
through Heath-Zenith—the security of 
Heath-Zenith support. If you order 
your drive through a reputable mail¬ 
order house, you will still get help if 
you need it. Of course, if you get a 
Seagate or Priam drive, you are dealing 
with companies that want to keep con¬ 
sumer confidence in their products, so 
you can always get in touch with their 
technical support staff. There’s another 
way to look at this: Do you want to pay 
for the confidence that someone will 
hold your hand through the installation 
if you have a problem, or would you 
rather have 160-Mbytes of disk storage 
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for just under what Heath-Zenith 
charges for 40-Mbytes of storage? 

No matter which of the drives you 
pick, The Hard Disk Companion by 
Peter Norton and Robert Jourdain 
(Brady Books) is a must. This new book 
contains just about everything you 
could want to know about hard disks. 

In addition to providing clear, detailed 
technical explanations about hard disk 
operations and problems, it also tells 
you all you need to know about install¬ 
ing them. So even if the installation 
instructions for your drive aren’t clear, 
Norton’s book will help you through it. 
And if you’re not sure which disk drive 
to buy, or even which technology to 
buy, this book will help you decide. 

Backup with Fastback Plus. Backing 
up your hard disk has always been 
important, but using DOS Backup and 
Restore has always been painful. With a 
large-capacity drive, the importance 
and pain both increase. Unless you’re 
planning to get a tape backup system, 
what you need is a program that per¬ 
forms the backup and restore at high 
speed. Fastback Plus, from Fifth 
Generation Systems, is just such a pro¬ 
gram. A greatly improved version of 
their Fastback program, Fastback Plus 
makes it easy and convenient to back up 
and restore. 

Fastback Plus also performs data 
compression, which reduces the number 
of diskettes you must track. For exam¬ 
ple, I backed up 17 Mbytes of mixed 
data—source and binary—on 11 
1.2-Mbyte diskettes in just 10 minutes, 
and restored it to another drive in just 
eight minutes. I backed up 25 Mbytes of 
Ada source on 13 1.2-Mbyte diskettes in 
just 11 minutes. If the diskettes aren’t 
formatted, Fastback Plus will format 
them as it goes along. 

Fastback Plus provides many options 
for easy use. For example, it’s easy to 
exclude and include files when backing 
up or restoring files. A macro capability 
saves you keystrokes. Even better. Fast- 
back Plus offers both incremental and 
differential backups. With an incremen¬ 
tal backup, which you would probably 
perform weekly, you back up any files 
not marked as backed up and then 
mark them. With the differential 
backup, which you would probably per¬ 
form daily, you still back up all files not 
marked as backed up, but the newly 
backed up files aren’t marked. Each 
time you perform a differential backup, 
you get all files not backed up at the last 
full or incremental backup. 

Anyone with a hard disk system 
should seriously consider getting Fast- 
back Plus. It can save you from losing 
valuable files, it’s easy to use, and it’s 


fast. Even if it weren’t only $189,1 con¬ 
sider Fastback Plus a must. 
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Preventing hard disk failures with 
Spinrite. Getting a fast hard disk and 
faithfully backing up the files on it is 
not enough. You also want to minimize 
potential disk-surface failures. Spinrite 
($59) from Gibson Research can help 
prevent these failures and also improve 
the performance of your hard disk system. 

Many things cause hard disk failures. 
Typically, when the contents of a hard 
disk sector are changed, the entire sec¬ 
tor is rewritten. This strengthens the 
magnetic image of the data in the sec¬ 
tor. But the sector’s ID header, used to 
identify the sector, is only written when 
low-level formatting of the disk is per¬ 
formed prior to its use. With time, the 
header image can weaken, resulting in 
“Sector not found” messages when you 
try to read or write to the sector. 


Spinrite minimizes 
potential disk-surface 
failures. 


Other problems can occur. For exam¬ 
ple, if you have a hard disk without 
automatic parking and you don’t park 
the heads, you’re asking for trouble. 
When the system is powered on, the 
electric current escaping from the 
drive’s head amplifiers is turned into a 
magnetic pulse by the read/write heads. 
This magnetic pulse can soften the data 
positioned under the heads when the 
system was powered down. 

As another example, the stepping 
motor, which positions the heads over 
the proper tracks, causes the heads to 
jump sideways. This jumping occurs 
while the heads are still in contact with 
the disk surface. During the jump, weak 
latent magnetism carried by the heads 
can weaken whatever information is 
under them. The jumping can also 
cause drifting in drive head alignment. 

Spinrite can help circumvent these 
and other problems. It can electroni¬ 
cally realign the drive heads, reinforce 
the data and low-level formatting, and 
provide extensive surface-defect detec¬ 
tion on your hard drive. All of this can 
be done without backing up and restor¬ 
ing your hard disk. That alone is worth¬ 
while. Even better, Spinrite can adjust 
your hard drive’s interleave. According 


to Gibson Research, many performance 
problems in hard disk systems result 
from improper interleave. 

A hard disk controller can only oper¬ 
ate on one sector at a time. To get good 
performance from your hard disk sys¬ 
tem, this means that the next logical 
sector should not appear under the 
heads until the controller is ready to 
search for it. For this reason, logical 
sectors are spaced on the track to give 
the controller time to get ready to access 
the next sector. The interleave deter¬ 
mines the spacing of these sectors on 
the track. 

I tried Spinrite on all four drives I 
used for this review. The Heath-Zenith- 
supplied drive and the two Seagate 
drives had the correct interleave. How¬ 
ever, the Priam drive had an interleave 
that actually required 17 revolutions to 
read an entire track. After Spinrite 
adjusted the interleave, it required only 
three revolutions. Adjusting the inter¬ 
leave increased the data transfer rate 
566 percent, resulting in a significant 
performance increase. 
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VGA cards 

In addition to the Z-449 VGA card 
from Zenith, I looked at two more 
cards: the VIP VGA card from ATI 
Technologies and the VEGA VGA card 
from Video Seven. All three cards sup¬ 
port software written for EGA, CGA, 
MDA, Hercules, VGA, and MCGA 
modes. Each card worked well with the 
ZCM-1490 analog monitor described 
earlier. While the VEGA and Z-449 
gave slightly better text resolution than 
the VIP, any one of the three would be 
acceptable. 

Z-499.The Z-449 is a full card that 
you can plug into an 8-bit expansion 
slot. It has both a 15-pin connector for 
analog monitors, as well as a standard 
nine-pin connector. In addition to the 
standard graphics and text modes, the 
Z-449 also supports 135 x 25 text mode. 
To get the most out of this card, you 
need a multisync monitor. The card 
contains 256 Kbytes of video memory. 
Before installing the Z-449, you must 
set switches and move jumpers to con¬ 
figure the card for your monitor. 

The Z-449 has an auto switching 
capability that lets it switch between 
EGA and CGA modes, or MDA and 
Hercules modes. Software supplied with 
the Z-449 lets you do this yourself, but 
the auto switching is much more con¬ 
venient. 
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The Z-449 comes with software that 
you can use to enhance the output of 
products such as AutoCAD, GEM, and 
Lotus 1-2-3. A screen-saver feature lets 
you protect against phosphor burn-in, 
which can occur if a particular image is 
active on the monitor for a long time. 
The screen-saver feature lets you specify 
how long the display should stay on the 
screen if no keyboard entry occurs. If 
the screen goes off, hitting any key will 
turn it back on. You can turn this fea¬ 
ture on and off. 

I had no compatibility problems with 
the Z-449 card, but the documentation 
that came with the card does not pro¬ 
vide any useful information for soft¬ 
ware developers. Of course, if'you get 
this with an H-386, the technical refer¬ 
ence manual provided with the H-386 is 
more than enough. 
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VIP card. The ATI Technologies VIP 
is a compact card containing both a 
15-pin analog connector and a standard 
nine-pin connector. I found the VIP 
much easier to handle than the larger 
Z-449. Just as in the case of the Z-449, 
you must move jumpers and set switches 
to configure the card. 

The VIP card provides much more 
than the auto switching of other VGA 
cards. EGA, CGA, MDA, and Hercules 
software can run on analog, multisync, 
EGA, and TTL monochrome monitors. 
On a TTL monochrome monitor, EGA 
and CGA are emulated using shading. 

I used VIP on my AT clone, with a 
TTL monochrome monitor and the 
Inboard 386/AT. Software I used to 
test the card included Windows/386 
and Excel from Microsoft, and Design- 
CAD 3-D from American Small Busi¬ 
ness. I was really pleased with the 
results. If you need EGA capability, but 
only have a TTL monochrome monitor, 
you get the capability from the ATI 
without having to buy an EGA moni¬ 
tor. Recently advertised in a PC maga¬ 
zine for $299, VIP is a great buy at half 
the cost of the Z-449, even with the lit¬ 
tle bit of resolution lost on the ZCM-1490 
monitor. 

In addition to the standard graphics 
and text modes, VIP also supports 
132x25 and 132x44 text mode. With a 
multisync monitor, you can get 800 x 560 
high-resolution graphics in 16 colors. 

The card contains 256 Kbytes of video 
memory. It comes with drivers for vari¬ 
ous software packages and provides a 
screen saver feature. Software to 
change emulation mode is also provided. 

I didn’t have any compatibility prob¬ 
lems with the VIP card. The documen¬ 
tation, although terse, is sufficient to let 


you take advantage of the advanced 
modes provided. 
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The VEGA card. The VEGA card 
from Video Seven is also a compact 
card. Like the other two cards, it has a 
15-pin analog connector and a nine-pin 
standard connector, and must be con¬ 
figured by setting switches and moving 
jumpers. And like the VIP, this card is 
reasonably priced. The VEGA was 
recently advertised in a PC magazine 
for $289, again half the price of the 
Z-449. 

The VEGA card supports graphics 
modes of 752x410 and 800x600 in 16 
colors, but requires a multisynch moni¬ 
tor. With an analog monitor, VEGA 
also supports 320 x 200 in 256 colors 
and text modes of 80 x 60 and 132 x 43. 
As with the other two cards, it has 256 
Kbytes of video memory. Drivers sup¬ 
port standard applications, and a screen 
saver feature is provided. The documen¬ 
tation is good enough for installing the 
card, but little else. 

I did have some compatibility prob¬ 
lems with VEGA. When I tried to 
install it in TTL monochrome mode in 
my AT clone, the display wouldn’t 
come on. When I used it in the H-386 
with an editor (part of the Final Word 
II document preparation system), prob¬ 
lems occurred when I hit the PgDn and 
PgUp keys. The image on the screen 
split in two, with the text in the top half 
repeated in the bottom half. The only 
way I could clear it up was to get out of 
the editor and load it again. 
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Extra help on graphics cards. A new 
book published by McGraw-Hill can be 
a useful reference for EGA/VGA users. 
EGA/ VGA: A Programmer’s Refer¬ 
ence Guide by Bradley Kliewer discusses 
compatibility issues and all the text and 
graphics modes, with special emphasis 
on EGA and VGA modes. Several 
detailed chapters, with code listings, 
discuss programming for these cards. If 
you’re new to EGA/VGA graphics, you 
might want to take a look at this book. 


Communications hardware 
and software 

For communications, I looked for a 
low-cost modem and powerful commu¬ 
nications software. Since space on my 
desk is at a premium, I looked for a 
modem that I could plug into an expan¬ 
sion slot. I chose the HC2400 from 


Zoom Telephonies. For the communi¬ 
cations software, I chose Vterm 220 
from Coefficient Systems. 

HC2400. The Zoom HC2400, a short 
card, can fit into an XT or AT slot. 
This Hayes-compatible modem sup¬ 
ports 300, 1200, and 2400 bps. One of 
the nice features of the HC2400—in 
addition to its low cost of $199—is its 
automatic detection of speed, parity, 
and number of data/stop bits. 

If you are already using COM1 and 
COM2, you can also configure the 
HC2400 for COM3 or COM4. Unless 
you need to change from the default 
COM1 setting, you can just plug in the 
HC2400 and start using it. It provides 
the features that you would expect in a 
modem: full- and half-duplex opera¬ 
tion, auto originate and auto answer 
modes, and support for touchtone or 
rotary telephones. The well-written 
owner’s manual provides complete 
documentation on how to use your 
modem effectively. 

Included with the HC2400 is 
Procomm communications software. 
Procomm is acceptable if you don’t 
already have communications software, 
but it has too many menus for options 
and requires you to look through a 
screen full of them before you find 
what you want. Nonetheless, it does 
work, and it does come free with the 
HC2400. In its favor, the faster 
16-MHz speed of the H-386 and the 
Inboard 386/AT did not cause it any 
problems. 
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Vterm 220.1 prefer Vterm 220 over 
other communications software because 
I find it so easy to use. After I installed 
it, it was ready to run. I didn’t have to 
change a single setting. Vterm 220 has a 
few logical, easy-to-read menus, includ¬ 
ing a setup menu with four displays and 
a help menu that lets you quickly see 
the commands. 

In addition to providing full 
implementations of Kermit and Xmo¬ 
dem, Vterm 220 lets you do the things 
you want to with a communications 
package, but it doesn’t get in your way. 
You can do file transfers to your printer 
or a hard disk. You can use Vterm 220 
as a VT220 terminal, as a VT100 termi¬ 
nal, or as a VT52 terminal. 

Vterm 220 and the Zoom HC2400 
worked well together. I used them both 
with a touchtone phone and a rotary 
phone. Vterm 220 didn’t have any prob¬ 
lems with the 16-MHz speed of the 
H-386 and the Inboard 386/AT. If 
you’re not satisfied with your commu- 
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nications software, I recommend Vterm 

220 . 
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The Complete Answering Machine. 

One of the things I wanted to know 
about using a 386 system was what 
impact intensive background processing 
would have on foreground processing. I 
also wanted the background activity to 
happen randomly, while I was using 
different foreground applications. 

For the background processing, I 
decided to install The Complete 
Answering Machine (CAM) from The 
Complete PC. CAM is a voice mail sys¬ 
tem on a short card. It records messages 
on your hard disk. You can control it 
from CAM software or through a 
touchtone phone. 

You can record your own greetings, 
keep a file of them, and select the 
appropriate one as necessary. For 
example, you might have your standard 
greeting, a vacation greeting, and an 
out-of-town-for-the-day greeting. Just a 
few simple keystrokes on the keyboard 
or on your phone and you can change 
your greeting. 

You can listen to your messages and 
greetings over the phone. But if you 
connect a speaker to CAM, you can lis¬ 
ten to them through the speaker. The 
voice quality is not bad. You can actu¬ 
ally recognize the caller’s voice. 

Since CAM is installed in a computer, 
it has powerful programming capabili¬ 
ties. My standard greeting tells the 
caller to dial 0 to reach the receptionist 
if he or she doesn’t want to leave a 
recorded message. This uses my phone’s 
call-transfer capability. My greeting 
also tells the caller that he or she can 
dial 9 after leaving a message to listen 
to the message just left, erase the mes¬ 
sage, replace the message, or add more 
to the message. Although I didn’t pro¬ 
gram it do so, I could even let the caller 
transfer to another number. I can also 
program CAM to call me at another 
number and tell me that I received a 
message. 

Using a remote touchtone phone, I 
can listen to my messages or program 
CAM. When I ask to listen to messages, 
a prerecorded voice tells me how many 
messages I have. When I ask to listen to 
a message, CAM tells me the date and 
time the message was recorded. I can 
even save messages and easily distin¬ 
guish between them. 

CAM has many other features that I 
didn’t try. For example, you can record 
a message, give a date, time, and tele¬ 
phone number, and then have CAM 
deliver the message to that number at 
the specified date and time. It won’t 


start playing the message until it recog¬ 
nizes a human voice. If there is no 
answer, it will retry dialing a specified 
number of times at a specified frequency. 

CAM is really versatile. It can sup¬ 
port up to 999 voice mailboxes, each 
password-protected and each capable of 
having its own set of greetings. But this 
versatility does cost something. It 
requires 1.5 Mbytes for the software, 
and about 3,300 bytes for each second 
of recorded speech. While you can con¬ 
trol the length of messages, even if you 
keep them short, supporting many users 
will eat up disk space. But if someone 
administers the system, you can mini¬ 
mize disk usage. 

You can install up to four CAMs. 

This way, if one CAM is busy, addi¬ 
tional incoming calls can still be han¬ 
dled. Surprisingly, CAM only costs 
$349 and requires only a PC AT with 
hard disk and DOS 3.0 or better. If you 
need an answering machine capability, 
it would be hard to beat CAM. 

As far as the background activity of 
CAM, I only noticed a problem when 
the foreground application was disk 
intensive at the same time that CAM 
accessed the disk. In particular, one text 
editor that I used did constant auto¬ 


Product notes 

• Look to Covox for low-priced 
and high-quality digitized speech sys¬ 
tems. At $79.95, the Voice Master 
makes digital recordings of speech, 
sound, and music. Graphics-based 
editors allow for cutting and pasting 
of the sound waveform. Playback is 
provided by the $69.95 Speech 
Thing, which is a full-featured, 

8-bit, D/A sound converter that 
attaches in-line with the parallel 
printer port on a PC. Software 
includes several voice-output appli¬ 
cations. Covox can be reached at 675 
Conger Street, Eugene, OR 97402, 
phone (503) 342-1271. 

• Rational Systems, 220 N. Main 
St., PO Box 480, Natick, MA 01760, 
phone (617) 653-6006, has announced 
the release of DOS/16M, which 
enables developers working under 
MS/DOS to create programs that 
directly address a full 16 Mbytes of 
memory. Now users can create larger 
protected-mode programs on 80286 
and 80386 machines without switch¬ 
ing to a new operating system. 


matic backups of the text buffers. 

When a call came in, the keyboard 
response slowed down every few 
seconds. When I increased the duration 
between backups, the problem went 
away. So it seems that computationally 
intensive foreground and background 
tasks won’t slow you down. It’s only 
when both use the disk a great deal that 
you’ll notice a delay. 
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Summing up 

I’ve gone through the many alterna¬ 
tives for configuring your own personal 
computer. The do-it-yourself approach 
offers a much wider range of compo¬ 
nents that you can tie together to make 
up a unique system fitting your needs. 
Of course, this leaves you on your own 
when it comes to installation and main¬ 
tenance. But the bottom line—how 
much it will cost—is directly under your 
control. And with today’s standardiza¬ 
tion, you can mix and match in such a 
way that you gain additional benefits in 
terms of performance and features. 


• Tektronix 4107 and 4115 termi¬ 
nal emulation software for the 
Macintosh II is available from Graf- 
point, 1485 Saratoga Ave., San Jose, 
CA 95129-4934, phone (408) 446-1919. 
Prices are $995 for TGRAF-07 and 
$1495 for TGRAF-15LR. 

• For $195, Wang users can 
export documents directly from 
Wang WP 5 X-inch archive floppies 
into Ventura Publisher. A window 
interface is used to determine how 
the document will be translated. The 
product is available from Emulation 
Technologies, Bulkley Building, 

1501 Euclid Ave., Cleveland, OH 
44115, phone (216) 241-1140. 

• Western Digital has released a 
driver for its EtherCard Plus LAN 
adapter cards that supports PC- 
NFS*, the PC version of Sun 
Microsystems’ Network File System. 
Contact WD at 2445 McCabe Way, 
Irvine, CA 92714, phone (714) 
863-0102. 
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PC-based software checks AISC specs for structural engineers 


Fujitsu America has announced a 
PC-based software package that report¬ 
edly helps structural engineers ensure 
that their designs meet American Insti¬ 
tute of Steel Construction (AISC) speci¬ 
fication requirements. ElmCheck, 
which uses an AISC database of steel- 
beam shape properties, joins the Elm 


EEsof has announced OmniSys, a 
computer-aided engineering program 
that simulates microwave systems. The 
program uses component vendor cata¬ 
log data, internal component models, 
and external file component data to 
simulate linear and nonlinear micro- 
wave systems in the frequency domain 
and linear control loops in the fre¬ 
quency and time domains. 

OmniSys allows users to observe sys¬ 
tem response simulations for swept fre¬ 
quency, swept power, multi-tone 
spectrums, multi-tone intermodulation, 
noise parameters, mixer spurious inter¬ 


family of engineering software. 

According to the company, Elm- 
Check runs entire code checks, report¬ 
ing which sections passed or failed 
which equations. The graphics-based 
program features pull-down menus, 
beam icons, help screens, and a mouse- 
driven input window. It provides on¬ 


modulation, link parameters, and linear 
control loops. Simulations of mismatch 
effects are included. A budget table in 
spreadsheet form permits observation 
of system performance at internal 
nodes. 

OmniSys is available on IBM PCs 
and compatibles under MS-DOS and 
OS/2; Apollo; HY 9000 Series 300 
(third quarter 1988); and Sun and DEC 
VAX Series (fourth quarter 1988). 

Prices start at $12,000 and vary 
according to system and configuration. 


screen scaled representations of every 
beam and its dimensions for visual 
verification of input. 

Users can add custom beams or spe¬ 
cial applications to the database. 

ElmCheck costs $95. 

Reader Service 35 


Design synthesis system 
reduces ASIC design time 

Silc Technologies has announced Silc- 
Syn, a logic synthesis-based electronic 
design automation system for 
application-specific integrated circuits. 
According to the company, the pro¬ 
gram automatically generates gate-level 
structural implementations from high- 
level behavioral descriptions. Silc claims 
that the program provides library inde¬ 
pendence, ensures correctness, and 
guarantees testability. 

SilcSyn reportedly synthesizes com¬ 
binational and sequential logic, handles 
synchronous and asynchronous timing 
and single- and multiple-clock systems, 
and does not depend on programmable 
logic arrays or require a restrictive cir¬ 
cuit architecture. It can be targeted for 
any semicustom library. 

The system automatically synthesizes 
testability logic and incorporates it in 
the synthesized functional logic. The 
user can trade off between added testa¬ 
bility logic and testing time. The pro¬ 
gram then generates patterns for use in 
manufacturing testing of the fabricated 
chip. 

An open system, SilcSyn reportedly 
serves as a front end for existing 
CAE/CAD programs. It is also avail¬ 
able with a Mentor Graphics interface 
package, and the company will cus¬ 
tomize interfaces for specific programs 
according to customer demand. 

SilcSyn runs on Apollo workstations 
and DEC’S VAX family of computers, 
with versions for Sun Microsystems 
workstations scheduled for the end of 
the year. 

SilcSyn’s cost averages $40,000 per 
user. 



CAE program simulates microwave systems 


EEsof’s OmniSys, shown here on an IBM PC platform, simulates linear and non¬ 
linear microwave systems and subsystems. Reader Service 37 
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Production-test system targets VLSI 


SIA offers 25-MHz 386 PC 

Systems Integration Associates has 
announced the SIA 386/25, an 
80386-based PC with a second- 
generation motherboard reportedly 
designed for 25 MHz operation, cache 
memory for zero-wait-state operation, 
an ESDI hard disk drive with 

16.5- millisecond access time, and 

1,008-Kbytes-per-second throughput. 

According to the company, the 32-bit 
motherboard can handle up to 16 
Mbytes of memory. The 386/25 can 
accept 16 Mbytes of additional memory 
on a 32-bit add-on board, for a maxi¬ 
mum of 32 Mbytes. 

Users can add a 20-MHz or 25-MHz 
80387 math coprocessor to the mother¬ 
board. The Weitek 1167 coprocessor 
daughter board is also supported. The 
AMI BIOS is reportedly compatible 
with Windows 386, Unix, OS/2, and 
Novell NetBIOS. 

The SIA 386/25 standard configura¬ 
tion consists of four Mbytes of mem¬ 
ory, a 150-Mbyte hard disk drive, a 
1.2-Mbyte floppy disk drive, a serial 
and parallel port, and 101-key enhanced 
keyboard. It costs $10,920. 

Options include a 320-Mbyte 

14.5- millisecond hard disk drive, 
120-Mbyte tape backup, 360-Kbyte and 
1.4-Mbyte floppy drives, additional 
memory, and EGA and VGA adapters 
and monitors. 
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The Digital Products Group of 
Schlumberger/ATE offers the S1040 
production-test system, based on the 
MicroVAX II as the main system 
processor. A 68000 processor controls 
each test head. According to the com¬ 
pany, this architecture allows for simul¬ 
taneous program development and 
device testing. 

Multitechnology pin electronics 
reportedly permit the user to test both 
emitter-coupled logic and complemen¬ 
tary metal-oxide semiconductor tech¬ 
nologies. The system has up to 256 
full-function I/O pins and operates at 


test rates from 40 MHz to 80 MHz for 
VLSI testing. A timing system suppos¬ 
edly guarantees edge placement within 
250 picoseconds. 

Software tools assist the generation 
of test programs and functional test 
patterns, debugging, and characteriza¬ 
tion. CAD interface and tester simula¬ 
tion packages are available. 

Schlumberger offers a training pro¬ 
gram, with unlimited training credits 
for the first two years of ownership. 

Prices for the S1040 start at $746,000. 
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The S1040 VLSI production-test system from Schlumberger/ATE features a multi¬ 
processor architecture, CAD interface, and tester-simulation package. 


IDS 4000 electron-beam probing system spots device failures 


The Advanced Products Group of 
Schlumberger/ATE has announced the 
IDS 4000 electron-beam probing sys¬ 
tem. The system reportedly incor¬ 
porates DFI Application Tool, a 
commercial application of dynamic 
fault imaging. According to the com¬ 
pany, the DFI technique compares 
failed devices with known good devices. 

Users employ a graphics interface to 
DFI Application Tool to look at a 
failed part through various types of pas¬ 
sivation. Sequences of stroboscopic 
images of the device help users deter¬ 
mine the site of a failure. An image- 
comparison process yields a sequence of 
different images showing the propaga¬ 
tion of a fault. 

The IDS 4000 features adjustable 
beam energy to avoid unstable charging 
of the dielectric surface on certain passi¬ 
vated devices. A temperature-control 
option fosters diagnosis of temperature- 


sensitive IC failures, according to the 
company. 

The IDS 4000 is compatible with the 


IDS 5000 diagnostic workstation. It 
costs $395,000. 
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The IDS 4000 electron-beam probing system from Schlumberger/ATE features 
dynamic fault imaging, adjustable beam energy, and temperature control. 
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RISC chip set employs PACE technology 


Performance Semiconductor has 
announced the PACEMIPS R3000 
32-bit RISC processor chip set, based 
on the MIPS Computer Systems RISC 
architecture. According to the com¬ 
pany, the PACEMIPS R3000 CPU chip 
operates at a sustained rate of greater 
than 20 million instructions per second 
and seven million floating-point opera¬ 
tions per second single precision or four 
Mflops double precision when used 
with the floating-point coprocessor. 

The processor reportedly operates at a 
peak performance of 25 MIPS. 

The three initial grades offered 
include a 12-MIPS version in a 144-pin 
pin-grid-array package; and 16- and 
20-MIPS versions in 172-lead surface- 


Cordata Technologies has announced 
an IBM-compatible personal computer 
that the company claims runs both IBM 
and Apple software. WPC Bridge 
reportedly runs MS-DOS compatible 
software and many Apple lie and 
AppleWorks programs. 

WPC Bridge features a built-in 
12-inch monochrome monitor along 
with AT&T 6300 and CGA graphics 
with 640 x 400 resolution (720 x 360 in 
Apple mode). 

The PC comes with 512 Kbytes of 
RAM expandable to 768 Kbytes, two 
360-Kbyte 5/{-inch disk drives, three 
expansion slots, and an Apple nine-pin 


mount quad-packs. Also offered are 
three PACEMIPS R3010 floating-point 
units in 84-lead surface-mount packages. 

The 100-piece prices for the 20-MIPS 
PACEMIPS R3000 CPU and 
PACEMIPS R3010 are $895 each. 

The chip set is manufactured with 
PACE—performance advanced CMOS 
engineered—technology using 
0.8-micrometer effective gate lengths 
and two-level metalization and epitaxial 
substrates. Performance Semiconductor 
manufactures the chip set under a tech¬ 
nology, manufacturing, and marketing 
agreement signed with MIPS Computer 
Systems in 1987. 
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game port for joysticks. The machine 
supports IBM-compatible 3^-inch disk 
drives, external Apple drives, and CGA 
color monitors. 

Users can choose a 4.77-MHz, 
8-MHz, or Apple mode 1-MHz 
microprocessor speed. An IBM AT-style 
keyboard comes with the system. 

Each system comes with two self¬ 
booting MS-DOS tutorials, MS-DOS, 
and Electric Desk, a database, word 
processing, spreadsheet, and communi¬ 
cations program. 

WPC Bridge costs $1,695. 
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Motorola introduces new 
RISC microprocessor family 

Motorola has announced the 88000 
family, a new product line of reduced- 
instruction-set-computer microproces¬ 
sors. The family includes the 88100 
RISC Microprocessor and 88200 
Cache/Memory Management Unit. 

According to the company, the 88000 
series architecture couples pipelined 
floating-point and integer units on a 
single chip. It also incorporates a tech¬ 
nique called scoreboarding, which 
reportedly allows the processor to per¬ 
form as many as 11 operations concur¬ 
rently. 

The 88100 integrates an integer and 
two floating-point units. It supports six 
special function units. The 88100 con¬ 
tains 165,000 transistors. 

The 88200 CMMU includes memory 
management functions and 16 Kbytes 
of cache memory storage. It contains 
more than 750,000 transistors. 

According to the company, you can 
link multiple 88100s, with up to eight 
88200 CMMUs per processor. Both 
units reportedly have built-in fault- 
detection features to maintain data con¬ 
sistency in fault-tolerant systems. 

General sampling of the 88100 and 
88200 at 20 MHz is scheduled for the 
third quarter of 1988, with orders 
accepted in the fourth quarter. Initially, 
the 88100 will cost $495 in quantities of 
100 to 499. The 88200 will cost $795. 
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IBM-compatible PC runs Apple software 


IBM adds desktop and networking models to Personal System/2 family 


IBM has added the PS/2 Model 70 
386, the PS/2 Model 50 Z, and the 
PS/2 Model 25 LS to its family of Per¬ 
sonal System/2 computers. 

The Model 70 386 and Model 50 Z 
incorporate the Micro Channel architec¬ 
ture, DOS and OS/2 compatibility, a 
Video Graphics Array subsystem, and 
serial, parallel, and pointing-device 
ports on redesigned system boards. 

The Model 70 386 comes in three con¬ 
figurations. The 25-MHz and 20-MHz 
machines feature a 120-Mbyte fixed 
disk, while the 16-MHz machine has a 
60-Mbyte fixed disk. Prices range from 
$5,995 to $11,295. The 25-MHz model 
also includes an 82385 memory-cache 
controller. All three configurations 
have available an optional 80387 math 
coprocessor at the same speed as the 
microprocessor. 

The Model 50 Z comes in a 30-Mbyte 


or 60-Mbyte fixed disk configuration. It 
features 85-nanosecond system board 
memory, zero-wait-state operation, and 
a 10-MHz 80286 CPU. It costs $3,995 
for the 30-Mbyte version and $4,595 for 
the 60-Mbyte version. An optional 
80287 math coprocessor is available at 
the same speed as the microprocessor. 

The Model 25 LS adds an IBM 
Token-Ring Network PC Adapter Card 
to the standard Model 25. It comes with 
640 Kbytes of memory, a monochrome 
or color display, an 8-MHz 8086 
microprocessor with zero-wait-state 
operation, and Multicolor Graphics 
Array. It costs $2,139 for the Model 
25-L01 and $2,484 for the Model 
25-L04. 

Model 70 386: Reader Service 44 
Model 50 Z: Reader Service 45 
Model 25 LS: Reader Service 46 



IBM’s PS/2 Model 50 Z works as a 
stand-alone workstation or in a local- 
area or host-connected network. 
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RISC system for software development based on 88000 


Motorola has announced Platform-88, 
an 88000-based reduced-instruction-set- 
computer system for software develop¬ 
ment. Currently limited in availability, 
the system is scheduled for full ship¬ 
ment in the third quarter. 

Platform-88 is based on a 20-MHz 
88100 CPU and two cache memory- 
management units. It includes Unix 
System V.3. Optional languages and 
development tools include an assem¬ 
bler, a linker, a code scheduler, an 
optimizing C compiler, and an optimiz¬ 
ing Fortran compiler. 

The system comes with 8 Mbytes of 
parity memory with an optional exten¬ 
sion to 16 Mbytes. The basic unit also 
includes a serial I/O control for four 


asynchronous RS-232-C ports and one 
parallel printer interface. It includes a 
70-Mbyte streaming-tape drive, 364 
Mbytes of ESDI disk, and a 450-watt 
power supply and forced air cooling. 

Platform-88 costs $39,500. 

Motorola has also announced a cir¬ 
cuit board called Hypermodule for 
multiprocessing that holds up to four of 
the company’s RISC 88100 CPUs and 
up to eight 88200 Cache Memory 
Management Units. The board reput¬ 
edly delivers more than 50 MIPS sus¬ 
tainable performance. 

Motorola plans to offer five versions 
of Hypermodule, all with a compatible 
hardware interface and providing a 
common environment for software 


IDT claims fastest RISC chip set 


Integrated Device Technology claims 
to have the fastest 32-bit CMOS RISC 
microprocessor chip set available. Accord¬ 
ing to the company, the microprocessor 
achieves a sustained rate of 20 million 
instructions per second with a 25-MHz 
clock rate. 

The chip set results from IDT’s agree¬ 
ment with MIPS Computer Systems. 
Under that agreement, IDT is licensed 
to manufacture and market MIPS’ 

CPU, floating-point accelerator, and 
future peripheral components. The 
RISC chip set includes the IDT79R3000 
microprocessor, IDT79R3010 floating¬ 
point accelerator, and IDT79R3020 
write buffer. 

The R3000 microprocessor includes a 
programmable CPU, memory manage¬ 
ment unit, cache controller, 512 Kbytes 
of instruction and data caches, a trans¬ 
lation look-aside buffer, and a floating¬ 
point coprocessor interface. It operates 
at 20 MIPS with a 25-MHz clock rate. 

The R3010 floating-point accelerator 
performs floating-point calculations in 
parallel with the execution of program 


instructions. It supports the IEEE 
754-1985 standard and is benchmarked 
at 3.8 Mflops double-precision Lin- 
pack, according to the company. 

The R3020 write buffer allows the 
processor to perform write operations 
during run cycles. 

IDT also plans to offer software sup¬ 
port, consisting of the UMIPS version 
of the Unix operating system and 
optimizing compilers. 

Production of the IDT79R3000 is 
scheduled for September. The 
IDT79R3010 is scheduled for produc¬ 
tion in October. Mil-Std-883C and 
radiation-hardened versions are planned 
for 1989, according to IDT. 

The IDT79R3000 will come packaged 
in a 172-pin flat pack for $795 in lots of 
100. The IDT79R3010 will cost $875 for 
100 and up, packaged in an 84-pin, J- 
bend ceramic chip carrier. The 
IDT79R3020 will sell for $45 in lots of 
100 or more and will come in a 68-pin 
plastic leadless chip carrier. 
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InterACT offers compilers for Intel 80960 


InterACT offers a series of C, For¬ 
tran, and Pascal compilers for Intel’s 
80960 32-bit RISC processor, as well as 
a macro assembler for the 80960. The 
compilers support the C ANSI draft 
standard, ANSI Fortran-77 
(X3.9-1978), and Pascal ANSI/IEEE 


770 (X3.97-1983) standard. 

Depending on the host and network 
configuration, compiler and assembler 
licenses range from $5,000 to $40,000. 

Compilers: Reader Service 50 
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development and execution across 
88000 configurations. The boards will 
be available with one to four 88100 
CPUs and two to eight CMMUs, with 
up to 128 Kbytes of total cache 
memory. 

Initial versions of Hypermodule have 
a single 88100 CPU and two 88200 
CMMUs in pin grid array packages. 

The initial version costs $1,400 in quan¬ 
tities of 100 to 499. Samples will be 
available in the third quarter, with full 
shipment scheduled for the first quarter 
of 1989. 
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Intel introduces architecture 

Intel has announced a 32-bit micro¬ 
processor architecture that integrates 
reduced-instruction-set-computer design 
techniques. According to the company, 
the core 80960 32-bit architecture has 
parallelism and modular features for 
increased performance levels and devel¬ 
opment of market-specific, embedded 
control processors. The 80960KB and 
80960KA are the first available proces¬ 
sors based on the core architecture. 

On-chip functions of the 80960KB 
include 32 x 32-bit registers, a floating¬ 
point unit, a 512-byte instruction cache, 
a stack frame cache, and a 32-bit mul¬ 
tiplexed burst bus. The chip also has an 
interrupt controller with 256 interrupt 
vectors and 32 levels of interrupt priority. 

The 80960KA has the same configu¬ 
ration, but without the floating-point 
unit. 

The 80960KA and 80960KB are avail¬ 
able in 20-MHz CHMOS III configura¬ 
tions. The 80960KB costs $390 in 
100-piece quantities and comes in a 
132-lead pin-grid-array package. The 
80960KA, available in the fourth quar¬ 
ter, will cost $174 in 100-piece quanti¬ 
ties. The company plans to market 
25-MHz versions in early 1989. 

The Starter Kit 1 (SKitl) option con¬ 
tains the EVA-960KB software evalua¬ 
tion vehicle and the ASM-960 assembler 
for $6,000. It also provides minimal 
debug capability and limited bench¬ 
marking to the 80960KB. 

The Starter Kit 2 (SKit2) option adds 
the iC960 C language compiler with 
ANSI extensions. It costs $6,800. 

Processors: Reader Service 52 
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Teradyne expands A500 test systems 


Amdahl offers new 
mainframe series 


The Industrial/Consumer Division of 
Teradyne has expanded the A500 family 
of analog very-large-scale-integration 
test systems with the A510 Standard 
Linear Test System and the A520 Ana¬ 
log VLSI Test System. 

The A510 is a workstation-based 
standard linear test system with a vari¬ 
ety of instrumentation modules (dc, ac, 
rf, digital, time, etc.) for testing of stan¬ 
dard linear parts. It incorporates 
graphics-based programming using the 
company’s C-based IMAGE (Interac¬ 
tive Menu-Assisted Graphics Environ¬ 
ment) software, a dual computer 
architecture based on Sun Microsystems’ 
Sun-3, and a stand-alone simulator/ 
workstation capability. It also has up to 
four test heads and parallel testing 
capability. 

Typical configurations of the A510 
cost $250,000 to $500,000. Moreover, 


according to the company the A510 can 
be upgraded to an A520 Analog VLSI 
Test System. 

The A520 is a Vector Bus II-based, 
mixed-signal test system. It features 25 
MHz or 50 MHz speed, - 100 dB har¬ 
monic distortion performance, and a 
tester-per-pin architecture. The system 
supports a maximum of 40 analog and 
40 digital pins. 

Like the A510, the A520 is based on a 
dual Sun-3 computer architecture, uses 
a Unix operating system and C-based 
IMAGE software, and ties into the 
Ethernet TCP/IP network. 

Typical configurations for the A520, 
scheduled for delivery in the first quar¬ 
ter of 1989, will range in price from 
$650,000 to $1.1 million. 
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NetPro 386/25 features 82385 chip 


Simple-Net Systems has announced 
the NetPro 386/25 microcomputer. The 
system features a 25-MHz 80386 CPU, 
a 25-MHz 82385 cache controller chip, 
and a 64-Kbyte zero-wait-state cache. 
The standard configuration includes 
four Mbytes of static RAM expandable 
to eight Mbytes on the motherboard. 
Three models are available, configured 
with graphics and storage options. 

The company says that the machines 
are compatible with OS/2, DOS, and 
Xenix. The NetPro provides an AT- 
style expansion bus with slots for eight 
add-in cards, two serial ports, one par¬ 
allel printer port, and two 25-MHz 
32-bit memory expansion slots for up to 
24 Mbytes of total RAM. An optional 
80387 math coprocessor and 360-Mbyte 
hard disk will be available. 


The NetPro uses the Phoenix AT 
BIOS, supports VGA and monochrome 
graphics displays, and has the option of 
an EtherLAN Plus Ethernet adapter 
and software. 

The NetPro 386/25 costs $11,499 for 
a Model 0 with motherboard, four 
Mbytes of RAM, keyboard, and single 
floppy drive. Model 1 at $12,499 adds 
an 80-Mbyte fixed disk drive, mono¬ 
chrome graphics display, and Ether¬ 
LAN Plus Network Adapter with 
NetWare drivers. Model 2 adds a 
1.44-Mbyte 3K-inch drive and 120-Mbyte 
fixed disk drive plus a VGA color moni¬ 
tor for $13,499. 

The company requests a 50-percent 
deposit with all orders. 
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Amdahl has announced the 5990 
Series of processors. The new series 
includes a dual processor, the 5990-700, 
and a four-way multiprocessor, the 
5990-1400. According to the company, 
the new mainframes run industry- 
standard software. Amdahl also plans 
to support the MVS/ESA operating sys¬ 
tem announced by IBM in February 
1988. 

The series features 10,000- and 
3,000-circuit emitter-coupled-logic chips 
with 180-picosend switching speeds. 
Main storage uses SRAM chips with 
memory access times of 55 nanose¬ 
conds. Patrol circuitry reportedly reads 
periodically through main, expanded, 
and control storage, seeking out and 
correcting intermittent, single-bit mem¬ 
ory failures. Permanent errors prompt 
the feature to relocate data to alternate 
memory chips. 

The 5990 systems accommodate up to 
512 Mbytes of main storage and two 
gigabtyes of expanded storage. 

According to Amdahl, the new 
processors offer 4.5-Mbyte-per-second 
channels as a standard feature and the 
company’s Multiple Domain Feature as 
an option. MDF reportedly allows a 
mainframe to be partitioned into 
several systems that can run different 
operating systems simultaneously. The 
5990-700 supports up to four MDF 
domains; the 5990-1400, as many as 
seven in single-image mode or eight in 
partitioned mode. 

A basic 5990-1400 with 128 Mbytes of 
memory and 64 channels will cost 
$13,140,000 when available in the 
fourth quarter. A basic 5990-700 costs 
$7,070,000 with 64 Mbytes of memory 
and 32 channels. 
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ICL offers ISDN workstation with conferencing and teleprospecting 


International Computers Limited 
offers an ISDN Professional Worksta¬ 
tion with Desktop Conferencing and 
TeleProspecting applications. The 
workstation reportedly combines per¬ 
sonal computing with telephony fea¬ 
tures on a single ISDN line. It connects 
to AT&T’s 5ESS switch and Siemens 
EWSD, with connection to Northern 
Telecom’s DMS-100 planned. 

The workstation is compatible with 
the IBM PC AT and runs DOS applica¬ 
tions. It will be compatible with OS/2 
applications. 


Telephony features include multiple 
directories; manual, directory, speed, 
and recent-call dialing; a separate tele¬ 
phone unit; two-line operation; and sta¬ 
tus display. Communications features 
include 64-Kbyte B channel circuit- 
switched operation; directory setup of 
communication services; auto¬ 
answering; optional modem interface to 
non-ISDN services; X.25; MS-Net sup¬ 
port; IEEE 802.3 LAN support; and 
V. 120 rate adaptation. 

System options include one to eight 
Mbytes of RAM; a 5X-inch floppy disk 


drive with 360 Kbytes or 1.2 Mbytes; a 
20- or 45-Mbyte hard disk; color or 
monochrome monitor; and CGA or 
EGA graphics. 

Prices for the ISDN Professional 
Workstation range from $7,000 to 
$9,000. Conferencing software costs 
about $300 per copy, and TeleProspect¬ 
ing software costs about $1,500 to 
$2,000 per station. 

Workstation: Reader Service 58 
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DEC speeds development of Cray programs 


Digital Equipment has announced a 
set of software tools and services 
designed to speed development of appli¬ 
cation programs to run on Cray 
Research supercomputers, according to 
the company. The system is called VAX 
Software Development Environ¬ 
ment/Science, or SDE/Science. 

The product consists of the VAX 
SDE/Science Integration Package plus 
existing VAX hardware and software. 
The software was conceived and imple¬ 
mented as a research project at the 
Pittsburgh Supercomputing Center. 

DEC claims that the system allows 
researchers to more efficiently write 
new programs or convert existing VAX 
programs to run on Cray systems. Tem¬ 
plates allow programmers on VAX sys¬ 
tems to write code in Cray Fortran 77, 
Cray Fortran 1.15, and Cray C to be 
compiled on the Cray system. It also 
provides interfaces with Cray com¬ 
pilers, Cray communications software, 


and third-party scientific subroutine 
libraries. 

The Integration Package software 
uses extended versions of the VAX Lan¬ 
guage Sensitive Editor and the 
DEC/VAX Module Management Sys¬ 
tem. These utilities reputedly minimize 
errors in programming and speed pro¬ 
gram testing and maintenance. The ser¬ 
vices part of the package is offered by 
Digital’s service organization, with 
components ranging from evaluation of 
site readiness to user training. 

The VAX SDE/Science software is 
available for VAX single-system proces¬ 
sors in a time-sharing environment or 
on a local area VAXcluster. The soft¬ 
ware requires a DECnet connection to a 
Cray system and appropriate Cray soft¬ 
ware. The VAX SDE/Science Integra¬ 
tion Package will be available in the 
first quarter of 1989 for a license price 
of $15,503. 
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FlexCache 25386 features extended emulation 82385 


Advanced Logic Research has 
announced the 25-MHz, zero-wait-state 
FlexCache 25386, based on the dual-bus 
FlexCache architecture and the com¬ 
pany’s extended emulation of the Intel 
82385. 

According to the company, the ALR 
cache system features a 64-Kbyte, 
25-nanosecond static RAM caching 
memory between the CPU and main 
memory; DMA caching of RAM I/O; 
byte, word, or double-word caching; 
posted write-through on all accesses; 
and background refresh cycles. In addi¬ 
tion, the 60-nanosecond, one-Mbyte 
main memory (expandable to 14 
Mbytes) is parallel to the cache system. 


The floor-mount chassis can report¬ 
edly accept up to two full-height hard 
disk drives and three half-height 
devices. 

The Model 150 includes an 80386 
CPU, 25-MHz processor clock, 80387 
support, 64 Kbytes of cache memory, 
one Mbyte of main memory, one 
1.2-Mbyte 5X-inch floppy disk drive, 
one 150-Mbyte ESDI hard disk system 
with controller, one serial port, and one 
parallel port. It costs $9,499. 

The Model 300 has the same features 
as the Model 150, but adds a 300-Mbyte 
ESDI hard disk drive with controller. It 
costs $12,499. 
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Cray X-MP EA replaces X-MP series 


Cray Research has announced the X- 
MP EA (Extended Architecture) series 
of supercomputers to replace the X-MP 
series. The new systems are based on 
the architecture of the Cray Y-MP, 
introduced in February 1988. 

According to the company, the EA 
series implements the Cray Y-MP 
instruction set, as well as the instruction 
set of existing Cray X-MP systems. 
Users can switch processing modes 
through commands to the system. 

Extended Architecture systems 
reportedly allow up to 32 million words 
of buffer memory in the I/O subsystem. 


Clock cycle time is 8.5 nanoseconds 
except for the EA/14se and EA/116se, 
which have 10-nanosecond clock cycle 
times. 

The company offers the full set of 
Cray Research software, including 
operating systems, language compilers, 
programming tools, and utilities, for 
the EA series. 

Prices of Extended Architecture sys¬ 
tems range from $2.5 million to $14 
million. Customer shipments are sched¬ 
uled for the third quarter of 1988. 
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Supercomputer features 
parallel processing 

International Parallel Machines has 
announced the IP-1 supercomputer, 
which the company claims is a true par¬ 
allel processing machine. Multiple 
processors can reportedly access a 
shared memory simultaneously without 
arbitration. 

Other features include flash data 
transfer, in which the interconnection 
network allows one processor to send 
one Mbyte of data to another processor 
in less than one microsecond; a data¬ 
base consisting of 64-bit words with 
32-bit addressing expandable to 48-bit 
addressing; a standard library of more 
than 200 vector, matrix, and parallel 
routines; communication through a 
serial port, Ethernet local area network, 
or optional bus-to-bus interface at 
speeds up to 80 Mbytes per second; and 
real-time color 3D graphics with 
optional D-Scan GR4416 terminals. 

A one-processor system with vectoriz¬ 
ing compiler costs $49,000. This 
includes cabinet, terminal, disk drive, 
memory, and software. A nine- 
processor system (with nine times the 
memory of the single-processor system) 
costs $220,000. 
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Ashton-Tate offers word 
processing for Mac 

Ashton-Tate offers FullWrite Profes¬ 
sional, a word processing program for 
the Apple Macintosh. According to the 
company, the software combines word 
processing, page layout, and draw-type 
graphics. 

The program provides automatic 
updates of document outlines, move¬ 
ment between outline and full-text 
modes, visible formatting, and auto¬ 
matic generation of an index, bibliogra¬ 
phy, and table of contents. Moreover, 
members of a work group can insert 
comments within the document. 

Page layout features include multiple 
column-widths on the same page, text 
wrapping around graphics, kerning and 
leading controls, guttering, and facing 
pages. The software runs on the Macin¬ 
tosh II, SE, and Plus computers with 
one Mbyte of RAM (2 Mbytes recom¬ 
mended), an 800-Kbyte disk drive, and 
a hard disk. 

FullWrite Professional costs $395. 
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1C Announcements 


Company, Model, Function Comments 


Advanced Micro Devices 

Am29C332 

ALU 


Advanced Micro Devices 

Am27C010 

EPROM 


Bipolar Integrated 
Technology 
Floating-point chip set 
Multiplier & ALU 

Chips and Technologies 
82C575 

Micro Channel controller 

Hitachi America 

HD63487 

MIVAC 


Integrated Device 
Technology 
IDT7M137 
SRAM module 

Integrated Device 
Technology 

IDT7MC4032, IDT7M4017 
SRAM module family 


National Semiconductor 
DP8490, DP5380 
SCSI devices 


Signetics 

PLHS16L8B, PLHS18P8B 
PALs 


Texas Instruments 
TMS370 family 
Microcontrollers 


Toshiba America 

TC551001P/F 

SRAM 


White Technology 
Model M4194 Kbit 
SRAM module 


A 32-bit CMOS arithmetic logic unit that supports a pipelined Am29C300 system cycle 
time of 80 ns for performance of 12 MIPS. Features an 80-percent power savings over the 
bipolar Am29332, plus two input ports and one output port. Comes in a 169-pin PGA. 
Cost: $175 (100s). 

A 128K x 8 CMOS one-megabit EPROM with an access time of 150 ns. Comes in 32-pin 
DIP and LCC packages. Also available in other access-speed versions. Military APL and 
DESC versions scheduled. Cost: (100s) $29.05 (300 ns), $31.35 (250 ns), $38.45 (200 ns), 
$43.95 (170 ns), $54.95 (150 ns). 

A floating-point chip set consisting of a multiplier and arithmetic logic unit. The 
B3110A-50 multiplier and B3120A-25 ALU are ECL compatible. The B2U0A-50 mul¬ 
tiplier and B2120A-25 ALU are TTL versions. Cost: (100s) $565 each for 
B3110A-50/B3120A-25, $490 each for B2110A-50/B2120-25. 

A Micro Channel communications interface controller. Requires only a 74LS245 buffer for 
the data bus to interface to the Micro Channel. Supports dual resource allocators with up 
to 32 I/O address spaces. Comes in a 68-pin PLCC. Cost: $720 (1,000s). 

A memory interface and video attribute controller to control graphics memory, move 
images to a CRT screen at 33 million pixels per second, and display attributes. Adjustable 
parameters include resolution, number of colors, pixel shift rate, and frame buffer size. 
Comes in a 68-pin surface-mount PLCC. Cost: $25 (5,000s). 

A 32K x 8-bit CMOS dual-port static RAM module. Has two ports with separate control, 
address, and I/O pins. Consists of eight RAMs in LCCs mounted on both sides of a 
ceramic substrate. Also includes two FCT139 decoder circuits. Available in different speed 
versions. Cost: (100s) $507 (55 ns), $390 (60 ns), $310 (70 ns), $259 (90 ns). 

A family of 32-bit-wide SRAM modules. IDT7M4017 is a 64K x 32 module in a 60-pin 
DIP, consisting of eight IDT71256 SRAMs with on-board decoders. The IDT7MC4032 is a 
16K x 32 module with separate I/Os. It has eight IDT71982 SRAMs and comes in an 88-pin 
dual ceramic SIP. Cost: (100s) for IDT7M4017, $1,240 (45 ns), $907 (55 ns), $620 (70 ns)- 
for IDT7MC4032, $320 (30 ns), $238 (35 ns), $198 (45 ns). 

Both are pin-compatible with the NCR5380 SCSI device and consume a maximum supply 
current of 10 mA. DP8490 has an enhanced mode that opens three registers and requires 
software changes to use. DP5380 has the same speed and power features and input protec¬ 
tion. Both come in 40-pin DIPs and 44-pin PLCCs. Cost: $8 for DP8490, $7.50 for 
DP5380. 

Low-power programmable array logic devices with a maximum propagation delay of 15 ns. 
PLHS16L8B has eight dedicated inputs, two dedicated outputs, and six bidirectional I/Os. 
PLHS18P8B has eight more logic AND product terms. Both come in 20-pin plastic DIPs 
or PLCCs. Cost: (100s) for PLHS18P8B, $4.33 (DIP), $5 (PLCC); for PLHS16L8B, 


A family of configurable, 8-bit microcontrollers with on-chip options including EEPROM 
and an A/D converter. Based on a CPU and a modular bus. Now available: six standard 
part numbers and 16 function modules. TMS370C010/310 devices come in 28-pin plastic 
DIPs and PLCCs; TMS370C050/350 devices come in 68-pin PLCCs. Cost: $3-$7 for 
010/310; $4.50-$ 10 for 050/350. 

Organized as 131,072 words by 8 bits and comes in a 32-pin plastic DIP (P suffix) or SOIC 
package (F suffix). Available in 70-, 85-, or 100-ns speed versions. Has three control 
inputs: two chip enable inputs for device selection and data retention control, and one out¬ 
put enable. No prices given. 

A 4-Mbit SRAM module configurable as 512K x 8, 256K x 16, or 128K x 32. Consists of 16 
32K x 8 memory cells plus 19 other ICs for buffers, latches, decoders, control logic, byte 
selection, and timing. Can be ordered as a custom design with EEPROM and temperature 
options. Comes in a 76-pin flatpack. Cost: $995 (1000s). 


120 


121 


122 


123 


124 


125 


126 


127 


128 


129 


130 


131 


90 


COMPUTER 










ACM SIGGRAPH Symposium 
on 

User Interface Software 

October 17-19,1988 
Banff Park Lodge 
Banff, Alberta, Canada 


The ACM SIGGRAPH Symposium on User Interface Software is the first in a series of symposiums on 
the software aspects of user interface design and implementation. The symposium provides a forum for 
researchers and developers to discuss new research results in user interface software and the 
practical and research problems facing this field. The symposium consists of 12 sessions of invited and 
contributed papers, with ample opportunity to interact with other attendees. This symposium will 
present the latest research results, and provide the attendees with an in depth view of this new field. 

Paper Sessions 
Models 
Design Aids 

User Interface Presentation 

Panel Sessions 
User Interface Evaluation 

Invited Speakers (as of May 13) 

M. McGreevy 

NASA Ames Research Center 

Location 

The resort town of Banff is located in the heart of the Canadian Rockies. The mountains, hot springs, 
and other attractions in the town site are within a short distance of the hotel. Lake Louise and the 
Columbian Ice Fields are within an easy half day trip of Banff. 


Toolkits Tools 

Interactive Ul Design Applications 


Corporate Issues 


W. Teitelman 
Sun Micfosystems 


Registration Fees 

ACM/SIGGRAPH Members 

Non-members 

Students 


Before Sept. 1, 1988 
$275.00 
$325.00 
$150.00 


After Sept. 1, 1988 
$325.00 
$375.00 
$150.00 


All registration fees are in $US. Advance programs and registration information were mailed to 
SIGGRAPH and SIGCHI members in late June. Registration information can be obtained from either: 


Dan Olsen 

Computer Science Department 
Brigham Young University 
Provo, Utah 84602 


Mark Green 

Department of Computing Science 

University of Alberta 

Edmonton, Alberta, Canada T6G 2H1 


Conference Committee 

Mark Green, James Rhyne, Gurminder Singh, Dan Olsen, Michelle Lund, John Sibert 


Program Committee 

Dan Bergeron, Jim Foley, Mark Green, Deborah Hix, Rob Jacob, Keith Lantz, Dan Olsen, Elaine Rich, 
Kurt Schmucker, Mark Weiser 



Microsystem Announcements 


Company, Model, Function_Comments_ R.S. No. 


American Eltec 
Eurocom 6 

Single-board computer 


CalComp 
Model CGS-4700 
Graphic subsystem 


Cognex 
Cognex 3000 
Vision system 


Features an MC68030 at 20, 25, or 33 MHz; an MC68882 floating-point coprocessor; a 32 
VME and VSB interface; 4 Mbytes of DRAM (8 Mbytes optional); six programmable 
16-bit counters/timers; 20 parallel I/O lines; four RS-232-C serial ports; and VMEbus sys¬ 
tem controller. Cost: $3,212 (100s). 

A Formula 1 Series, 68020-based, graphic subsystem for the DEC Micro VAX II. Has color 
graphics with a resolution of 1,280 x 1,024 pixels. Comes as a graphics subsystem including 
color monitor, keyboard, and mouse or digitizer, or as a graphics engine alone, occupying 
one VME slot. Cost: $4,995 (card), $9,995 (system with 19-inch monitor). 

A single-board vision system based on the VC-1 custom vision chip and a 25-MHz Motor¬ 
ola 68020 CPU. Scheduled for beta testing in fall 1988 and shipment to OEMs in early 
1989. Cost: $12,500-$30,000; $49,000 for development system with 8 Mbytes of memory 
and peripherals. 


CSPI 

MAP-4000 
Accelerator board 

DY-4 Systems 
DVME-137 
Single-board computer 

Force Computers 
PDS-386 

Development system 


A MicroVAX-based application accelerator with peak performance of 40 Mflops single¬ 
precision and 20 Mflops double-precision floating-point. Comes with 2 or 8 Mbytes of 
memory expandable to 256 Mbytes. Cost: $18,995 (2 Mbytes), $22,500 (8 Mbytes). 

A 68020-based, 25-MHz, VMEbus, single-board computer with 4 Mbytes of zero wait-state 
DRAM. Includes two serial ports, sockets for standard 28-pin EPROMs, and three 16-bit 
counter/timers. Features a general-purpose monitor and self-test diagnostics. Cost: $7,400. 

An application development system for 80386-hosted applications on the VMEbus. Com¬ 
bines a software toolkit and target development hardware for use on PCs running under 
MS-DOS. Also available on VAX computers. Cost: $4,990; $2,990 for the CPU-386 single¬ 
board computer. 


Fujitsu America 
M2263E 

Winchester disk drive 


A 5X-inch Winchester disk drive with 778 Mbytes of unformatted capacity, a 1.87-Mbyte/s 
data transfer rate, and a 16-ms average positioning time. Features spindle synchronization 
capability, eight media platters, and 15 read/write data heads. Has initial ESDI interface, 
with SCSI interface in third quarter. Cost: $3,170 (100s). 


Hewlett-Packard A video graphics subsystem consisting of a color or monochrome monitor and a video 

HP video graphics subystem graphics adapter. The HP VGA offers 800 x 600-pixel resolution and up to 132 columns of 
Graphics subsystem text. Memory expands from 256 to 512 Kbytes. Cost: $695 for color display, $250 for mon¬ 

ochrome display, $445 for VGA. 


Mass Micro Systems 
Data Pak 

Removable hard disk 


A hard disk with removable 44.5-Mbyte, 5X-inch cartridges for the Apple Macintosh SE 
and II. Comes with Pad Lok software that lets Mac users partition the hard disk into up to 
10 volumes with optional password security. Cost: starts at $1,775. 


MicroDirect Combines the MicroDirect Turbo Laptop computer, ink jet printer, optional portable cel- 

Complete Portable Office lular telephone, and modem/cellular interface. Comes with an 80C88 CPU, one Mbyte of 
Bundled laptop system RAM, 80-column text display, two floppy disk drives or one floppy and one hard disk 
drive, 1,200-bps modem, four ROM sockets, and batteries. Cost: ranges from 
$4,995-$5,500. 


Ovation Systems 
VMEsram 
VME slave board 


Quadram 
JT Fax PS/Q 
PC fax board 


The Complete PC 
CFAX/9600 
PC fax board 


Compatible as a slave board to VMEbus Rev. C. Has eight 28/32-pin sockets that can take 
up to one Mbit RAM or PROM devices. Access times of 45, 60, or 110 ns. Optional zero- 
wait access on read and write cycles. Supports address pipelining and unaligned transfers. 
Has on-board power-fail detection and rechargeable Ni-Cad batteries. No price given. 

A PC facsimile board compatible with the IBM PS/2 Micro Channel. Based on a 4,800-bps 
chip. Automatically strips out printer command sequences, converts a file into fax format, 
and sends it simultaneously. Features menu-driven software. Operates on a terminate-and- 
stay-resident basis. Scheduled for third quarter 1988. Cost: below $600. 

A hardware/software system that operates in background mode to send and receive facsi¬ 
miles on the PC. Has an on-board port for a scanner and accepts an optional 2,400-bps 
Hayes-compatible modem. Features direct word-processor-to-fax operation, automatic 
cover sheets, automatic redialing, and on-screen viewing. Cost: $599. 
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CALL FOR PAPERS 

The 9th 
International 
Conference on 

Distributed Computing Systems 

June 5-9,1989 • Newport Beach Marriott Hotel • Newport Beach, California 


Theme: Distributed Computer Systems: Putting the Pieces Together 

The field of distributing computing systems has matured from solely an object of academic research to there®!*'?. n h 0 r * n 0 . p f a ' 
tional systems. The objective of this conference is to focus on the integration of the elements which are required to bring a 

svstem from the research phase to the operation and maintenance stage. .__ . . 

Four elements (concepts and resources) are required to develop, implement and apply a computer system, development strat¬ 
egy land™ esignapproachTte^ tools, and application and maintenance. These elements are crucial for distri¬ 

buted systems because of their greater complexity as compared to centrally managed systems^ For a distributed sy^em to 
evolve from a research concept to use, answers must be found to the questions suggested by the elements. For example. 

□ Development Strategy: How should software, hardware and databases be allocated among the nodes in a distributed com- 

□ Technology Base: What operating system and hardware characteristics are needed to support the selected development 

□ Tools^What modeling tools are available to assess the performance of the selected development strategy and operating 


□ Application and Maintenance: How effectively can the users apply and maintain the distributed computing system which 
results from applying development strategies, technology base and tools? 


Track 1: Distributed Algorithms/Resource Allocation & 
Scheduling 

Track 2: Distributed Data Base Systems/Reliability & 

Fault Tolerance 

Track 3: Distributed Operating Systems 
Track 4: Distributed System Architectures-Commumcation 
Software, Work Stations, and Experimental Systems 


Track 5: Languages/Modeling and Performance Evaluation 
Track 6: Software Engineering/Software Tools 
Track 7: Distributed Expert Systems/Group Decision 
Support Systems 

Track 8: Software Maintenance/Testing and Debugging 
Techniques 


Authore'are'cordiaHy invited^fubmit papers to the program chairman All papers will be "Sorouslyre^ u S the 

lanauaae of the conference To be accepted a paper must have substantive technical content, be highly readable, and be 
written 9 in correct English. Papers which require substantial revision will not be accepted. Authors of accepted papers are 
requfreitrpresentthefrpapers at the conference. Authors are requested to des gnate a conference track.and oneor more 
topics within a track. Authors are not limited to the topics listed above. Feel free to sub ^’.' t ^' °{ b ^ r n a fjf p r o t o 

they relate to the field of distributed computing systems. Some other possibilities are: Distributed Control Techniques, Proto 
col Specification and Design, Distributed System Security and Local Area Networks. 

I,ISIS 0NE paseWi,h F ' VE “"'“W Norman Schneidewind 
Circle primary author's name r^H® l = P 4li 9raduate Sch00 ' 

Primary Author's Address: C°de 54Ss 

Primary Author's Electronic Mail Address: Monterey, CA 93943 

Primary Author's Telephone Number: 

Title of Paper: 

Track: (write none’ if your topic does not fit a track) 

Topic(s): 


(408)646-2719/2471 
a. isi. edu 

Compmaikn. schneidewind 


A workstation exhibit is planned as part of the conference. 


General Chairman 

Kane Kim 

University of California 
Computer Engineering 
Program 

Electrical Engineering 
Department 
Irvine, CA 92717 
(714) 856-5542 
Ics.Uci.Edu 
Compmail: K.Kim 


Program Chairman 

Norman Schneidewind 
Naval Postgraduate School 
Information Systems Groups 


Local Arrangements 
Co-Chairmen 

Lubomir Bic 
University of California 

Mauro Dentino 
Rockwell International 
Microelectronics 
R&D Center 


Tutorial Co-Chairmen 
Andre van Tilborg 
Office of Naval Research 


Harut Barsamian 
University of California 


Treasurer 

Victor Nelson 
Auburn University 

Co-Treasurer 

Amir Abovelnaga 
TRW, Inc. 

Publications Chairman 
Ben Mortagy 

Naval Post Graduate School 

Registration Chairman 
Nader Bagherzadeh 
University of CA, Irvine 


Awards Chairman 

Mike Liu 

Ohio State University 


Advisory Committee Chairman 

C. V. Ramamoorthy 
University of CA, Berkeley 


Steering Committee Chairman 
Charles R. Vick 
Auburn University 


THE COMPUTER SOCIETY ^ 
OF THE IEEE 




















CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average six typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 
Los Vaqueros Clide, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“.. recent college grads...,” “...1-4 years 
maximum experience...,” “...up to 5 years 
experience...,” or “...10 years maximum 
experience.” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


CENTRE DE RECHERCHE 
INFORMATIQUE DE MONTREAL 
Computer Science Researchers 

The Centre de recherche informatique de 
Montreal (CRIM) is a non-profit corporation 
whose mission is the realization of research 
projects in collaboration with its university and 
industry members. CRIM is seeking Com¬ 
puter Science Researchers to work with its 
teams. Responsibilities: Participation in 
university-industry research projects. Prefer¬ 
red domains: Artificial Intelligence, software 
engineering, expert systems man-machine in¬ 
terfaces. Qualifications: The applicant must 
hold a Ph.D. in computer science with suffi¬ 
cient publications. Industrial experience is 
sought. In accordance with Canadian immi¬ 
gration requirements, priority will be given to 
Canadian citizens and permanent residents of 
Canada. Interested candidates may apply by 
sending a resume to: Dr. Jacqueline Bour- 
deau, Centre de recherche informatique de 
Montreal, 1550 de Maisonneuve Blvd. West, 
Suite 1000, Montreal, Quebec, CANADA, 
H3G 1N2. 


WRIGHT STATE UNIVERSITY 

Department of Computer Science 
and Engineering 

Applicants are invited for tenure-track and 
visiting faculty positions at all levels. There is 
particular interest in professors who have suffi¬ 
cient experience, currency, and depth to 
direct doctoral students and research disserta¬ 
tions in a PhD program in Computer Science 
and Engineering. Rank and competitive sal¬ 
aries are determined by qualifications and 
experience. 

The state supported university is located in 
a high technology environment among indus¬ 
trial/military research and development 
facilities. The graduate program has excellent 
offices and computing facilities in the WSU 
Research Center located in a fast growing 
associated state-assisted research park foster¬ 
ing basic and applied industrial/military/uni¬ 
versity research. The Center for AI Applica¬ 
tions and the Edison Materials Technology 
Center (EMTEC) funding organization are 
located in the same building. The University 
has identified computer science and computer 
engineering as an area of high priority for con¬ 
tinued development. 

Department strengths include a large facul¬ 
ty, extensive laboratory facilities including 
graduate laboratories in AI, optical com¬ 
puting, neural networks, and robotics, estab¬ 
lished research programs, industrial/military 
support, degree programs in both computer 
science and computer engineering, and large 
student populations at graduate as well as 
undergraduate levels. 

Successful candidates for tenure-track posi¬ 
tions should have a PhD in computer science, 
computer engineering, or equivalent back¬ 
ground and have demonstrated forward look¬ 
ing and creative research. 

Please submit a detailed resume including 
names of three references to: CSNET ad¬ 
dress: amcaulay@wright.edu or Alastair D. 
McAulay, NCR Distinguished Professor and 
Chair, Department of Computer Science and 
Engineering, Wright State University, Dayton, 
OH 45435. Reviewing for positions will begin 
immediately and continue monthly until posi¬ 
tions are filled or until January 1, 1989. 

An equal opportunity/affirmative action 
employer. 


SOFTWARE ENGINEERS 

Software R&D and consulting positions 
available at CCCC, which offers a new tech¬ 
nology for automatic programming. Experi¬ 
ence desirable in the following areas: IBM 
mainframes, VAX, PL1, C, Ada, training and 
documentation. Send resume to Evan Lock, 
CCCC, 2401 Walnut Street, Suite 402, Phil¬ 
adelphia, PA 19103. 


ROCHESTER INSTITUTE OF 
TECHNOLOGY 
School of Computer Science 
and Technology 
Software Engineering Position 

Visiting faculty position available in 
September or December for individual who 
has experience in the instruction of Software 
Engineering topics, both managerial and tech¬ 
nical. Ph.D. or Master’s (with professional ex¬ 
perience) degree in appropriate discipline re¬ 
quired. Duties will include teaching at the 
undergraduate and graduate (M.S.) level as 
well as curriculum development and applied 
research in Software Engineering. 

Send resume to Wiley McKinzie, Director, 

School of Computer Science, I Lomb 

Memorial Drive, Rochester, New York 
14623. 

RIT is an equal opportunity affirmative ac¬ 
tion employer. 


THE UNIVERSITY OF TENNESSEE 
AT CHATTANOOGA 

The Center of Excellence for Computer 
Applications (CECA) of The University of 
Tennessee at Chattanooga is seeking qualified 
applicants to fill the position of Fellow or 
Senior Fellow within the Knowledge Based 
Applications (KBA) Group. 

A doctorate in Computer Science (or a re¬ 
lated discipline) and significant experience in 
AI, including Knowledge Based Systems 
(KBS), Intelligent Tutoring Systems (ITS), 
and Natural Language Processing (NLP), is 
desired. For a candidate with appropriate ex¬ 
perience, advanced degree study might be ac¬ 
cepted in lieu of the doctorate. 

Academic rank and salary are open and will 
be determined on the basis of an applicant’s 
qualification. A twelve-month nontenured ap¬ 
pointment is possible. 

CECA has ongoing research in KBS, ITS, 
and NLP and is seeking a professional to com¬ 
plement and to strengthen its faculty in these 
activities. Ability to conduct applied research 
in above areas, as well as demonstrated ability 
to secure grants and contracts, is advanta¬ 
geous. CECA computer resources include an 
IBM 4381, TI Explorer LX, Tektronix 4405, 
and a comprehensive mix of microcomputers. 

A letter of application, a resume and the 
names and addresses of three references 
should be sent to: 

Professor Alex Bykat 
Chair of Search Committee 
Center of Excellence for 
Computer Applications 
The University of Tennessee at Chattanooga 
Chattanooga, TN 37403 
BITNET address: BYKAT2UTCVM 

The University of Tennessee at Chatta¬ 
nooga is an equal employment opportuni¬ 
ty, affirmative action Title IX, Section 504 
institution. 
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UNIVERSITY OF CALIFORNIA, 

LOS ANGELES 
School of Engineering and 
Applied Science 
Computer Science Department 
Endowed Chair 

We are seeking nominations and applica¬ 
tions for The Norman E. Friedmann Chair in 
Knowledge Sciences. The newly established 
professorial Chair shall be dedicated to the 
field of Knowledge Sciences and its allied 
fields of Artificial Intelligence, Software 
Engineering, Computer-Aided Software 
Engineering, Distributed Data Base Systems, 
Data Processing and Data Communications, 
and Information Sciences. The position will be 
at the level of full professor with tenure. Earn¬ 
ings from the endowment will be available to 
the Chair-holder for support of graduate 
students, travel, equipment, or other research 
purposes. Applicants must have a Doctorate 
degree in Computer Science or a closely 
related area, an international research reputa¬ 
tion in one of the areas described above, an 
outstanding ability to develop and lead a 
distinguished research program. The position 
will encompass teaching, research, and 
research supervision of graduate students. 
The Chairholder is expected to serve as a role 
model in research and instructional programs. 
Qualified persons are invited to submit a letter 
of application and a curriculum vitae to Pro¬ 
fessor A. N. Willson, Jr., Chairman, Search 
Committee for the Norman E. Friedmann 
Chair, School of Engineering and Applied 
Science, 7400 Boelter Hall, UCLA, Los 
Angeles, CA 90024. The deadline for ap¬ 
plication is January 31, 1989. UCLA is an af¬ 
firmative action, equal opportunity employer. 


SYSTEMS ANALYST 

Exam, evaluate and analyze multi-level ap¬ 
plication systems; Maintain and upgrade Data 
General MV10000 Comp, systems using 
AOS/VS operating system and CLI macro. 
Evaluate, improve existing or develops new 
systems to meet current and projected needs. 
Conduct reviews to insure functional/pro¬ 
jected systems are applied as designed and 
functioning satisfactorily. Interface with users; 
write users’ manual, train users. Must know 
ICOBOL; must communicate effectively; 
Familiar with Data General MV10000 Com¬ 
puter system and multi-level marketing ap¬ 
plication system. Requires 2 years experience 
with B.S. in Computer Science or M.I.S. Will 
accept M.S. in lieu of experience, $2,800/ 
mo. Send ad and resume to Sunrider Inti, 
3111 Lomita Blvd., Torrance, CA 90509- 
2840, Attn: Data Processing Dept. 


NAVAL POSTGRADUATE SCHOOL 

Computer Science Chairperson 

The Naval Postgraduate School invites ap¬ 
plications and nominations for the position of 
Chairperson of the Computer Science 
Department. We are seeking an individual 
who can provide leadership in both teaching 
and research to a strong and growing pro¬ 
gram. This person must have a Ph.D. in 
Computer Science or a closely related area 
and a distinguished record of research and 
publication as well as demonstrated adminis¬ 
trative capability. 

The Department offers M.S. and Ph.D. 
degrees in Computer Science. Currently, 110 
students are enrolled in the M.S. program and 
five in the Ph.D. program. No undergraduate 
degrees are offered. Students are military of¬ 
ficers or civilian employees of the Department 
of Defense and are fully supported by their 
sponsoring organization during their graduate 
studies. 

The faculty currently consists of thirteen full¬ 
time civilian faculty, five military faculty, and 
several adjunct faculty. Additional positions 
are open in all areas. Departmental facilities 
(supported by eight full-time computer profes¬ 
sionals) consist of six instructional and re¬ 
search laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory, and 
the Computer Science Academic Laboratory. 
In these laboratories are state-of-the-art com¬ 
puting equipment including a VAX 780, a 
VAX 785, LISP machines, high-performance 
graphics workstations, bit-mapped graphics 
workstations, and multi-microprocessor 
systems. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and letters of 
reference to: 

Chair Search Committee 

Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


NAVAL POSTGRADUATE SCHOOL 
Position Announcement in 
Computer Science 

The Department of Computer Science has 
immediate openings for faculty positions at all 
levels. Our primary interests are in the areas of 
operating systems, distributed systems, pro¬ 
gramming languages, and algorithms. Our 


secondary interests are in the areas of process¬ 
ing of visual data, real-time systems, and soft¬ 
ware engineering. An applicant should have a 
PhD in Computer Science or a related field 
and have a strong interest in both graduate 
teaching and research. Senior applicants must 
have distinguished research records. Appoint¬ 
ments can begin at any time during the year. 

The Department offers MS and PhD 
degrees in Computer Science. Departmental 
facilities (supported by 9 full-time computer 
professionals) consist of six instructional and 
research laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory and 
the Computer Science Academic Laboratory. 
In these laboratories are the latest, state-of- 
the-art computing equipment including LISP 
machines, high-performance graphics work¬ 
stations, bit mapped graphics workstations, 
multi-microprocessor systems, etc. During the 
academic year, the faculty normally teach for 
two quarters and conduct full-time research 
supported by major research programs in both 
the Department of Defense and the non-DOD 
organizations during the other two quarters. 
New faculty receive initial support from an on- 
campus research foundation. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and three 
letters of reference to: 

Search Committee 

Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 
AN EQUAL OPPORTUNITY/AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


SYSTEM ANALYST 

System Analyst—supporting medical re¬ 
search database; programming and maintain¬ 
ing clinical database; training of users for using 
databases and Unix based computers. Must 
have master’s degree in electrical engineering 
or computer engineering and six months ex¬ 
perience. Must have checkable references and 
experience with Unix and “C” computer lan¬ 
guages. Monday-Friday, 9-5, $13.05/hour; 
Send resumes to Job Service of Florida, 701 
S.W. 27th Avenue, Room 15, Miami, Florida 
33135, Job Order Number: FL5833069. 
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ASSISTANT PROFESSOR 
(Computer Engineering) 

A nonprofit institution of higher education 
in the Boston area has an immediate need for 
an Assistant Professor of Computer Engineer¬ 
ing to assume responsibility for teaching 
graduate and undergraduate courses in com¬ 
puter engineering; to conduct research in the 
field of multiple-valued logic design and its ap¬ 
plication to digital signal processing; and to 
establish a research program in the field of par¬ 
allel computer architecture and software 
design. Minimum requirements include a 
Ph.D. in Computer Engineering (or Electrical 
Engineering with emphasis on computer engi¬ 
neering); two years of relevant research ex¬ 
perience, at least one year of which included 
university teaching in an area of computer 
engineering at the Assistant Professor level. 
Also required are: extensive research in theo¬ 
retical and hardware aspects of multiple¬ 
valued logic design, particularly as such relates 
to delta-modulated digital filter design; ability 
to implement the hardware in CMOS VLSI 
technology; demonstrated ability to utilize 
Hamilton Technology’s CASE software 
needed to design a software environment for 
data flow parallel computer systems. Starting 
salary is $38,200 per year and also includes 
medical and life insurances, together with 
vacation and other academic institution- 
standard benefits. Qualified applicants re¬ 
spond with curriculum vitae and list of publica¬ 
tions to Job Order #8770. Massachusetts Divi¬ 
sion of Employment Security, C.F. Hurley 
Building, Boston, MA 02114. An EOE/MFH. 


UNIVERSITY OF ILLINOIS 
AT URBANA-CHAMPAIGN 
Supercomputer Center Staff 

The Center for Supercomputing Research 
and Development (CSRD) at the University of 
Illinois at Urbana-Champaign is engaged in 
the construction of the Cedar multiprocessor 
system that will deliver high performance over 
a wide range of computations. 

CSRD is seeking: 

Additional qualified technical staff with ex¬ 
pertise in the area of architectural simulation 
modeling and analysis to develop and imple¬ 
ment a parallel simulation faciltiy for high per¬ 
formance parallel systems. Should be familiar 
with C, FORTRAN and Unix-based worksta¬ 
tions, e.g. Sun. Knowledge of commercial 
simulation languages (i.e., Simscript II and 
GPSS) preferred but not required. 

Software Engineers and Senior Software 
Engineers for development of state-of-the-art 
parallelizing compiler and restructurers for C, 
Lisp, and FORTRAN. Should have formal 
education and experience in traditional com¬ 
piler techniques; on parallelizing compilers is 
preferred but not required. Looking for ex¬ 
perienced Unix Kernel programmers for 
multiprocessor extensions to Unix for the 
Cedar multiprocessor system; knowledge of 
multiprocessor scheduling techniques is 
desirable. 


Computer Scientists and Senior Computer 
Scientists for development and use of parallel 
algorithms in a number of engineering and 
scientific applications as well as design and im¬ 
plementation of numerical algorithms for the 
Cedar system. 

Seeking additional applicants with degrees 
in Computer Science, Computer Engineer¬ 
ing, Electrical Engineering, or closely related 
field for the following full-time regular posi¬ 
tions; the “visiting” titles are full and/or part- 
time temporary positions: 

For the following positions, Ph.D. prefer¬ 
red; M.S. with 4 years experience required: 

SENIOR COMPUTER SYSTEMS ENGI¬ 
NEERS and VISITING SENIOR COM¬ 
PUTER SYSTEMS ENGINEERS. To pro¬ 
vide expertise and technical leadership in 
development of state-of-the-art multiproces¬ 
sor architecture and hardware. 

SENIOR SOFTWARE ENGINEERS and 
VISITING SENIOR SOFTWARE ENGI¬ 
NEERS. To provide programming expertise 
and technical leadership in compiler develop¬ 
ment for parallel and array computers, operat¬ 
ing systems implementation, and instrumen¬ 
tation of parallel systems for performance 
evaluation. 

For the following positions, Ph.D. prefer¬ 
red; M.S. with 2 years experience required: 

SENIOR COMPUTER SCIENTISTS and 
VISITING SENIOR COMPUTER SCIEN¬ 
TISTS. To provide technical leadership in the 
development of multiprocessor numerical and 
nonnumerical algorithms in a variety of ap¬ 
plications, including graphics. 

For the following positions, M.S. or equiva¬ 
lent experience preferred; B.S. with 2 years 
experience required. 

COMPUTER SYSTEMS ENGINEERS 
and VISITING COMPUTER SYSTEMS 
ENGINEERS. To take part in research and 
development of state-of-the-art multiproces¬ 
sor architecture and hardware. 

SOFTWARE ENGINEERS and VISITING 
SOFTWARE ENGINEERS. To take part in 
research and development of the above soft¬ 
ware activities. 

COMPUTER SCIENTISTS and VISITING 
COMPUTER SCIENTISTS. To provide pro¬ 
gramming expertise and take part in research 
and development of the above numerical and 
nonnumerical algorithms. 

In rare instances, equivalent qualifications 
will be acceptable in lieu of those stated above. 

All positions provide salaries commensu¬ 
rate with experience. 

Please send resume including educational 
background, recent professional experience, 
and salary requirements to: 

Judy Reinhart 

Center for Supercomputing Research 
and Development 

104 S. Wright St., 305 Talbot Lab 

Urbana, Illinois 61801 217/244-0061 

Please specify the position (s) for which you 
are applying; otherwise, your application may 
be delayed. In order to insure full considera¬ 
tion, all applications should be submitted by 
August 12, 1988. Interviews may take place 
before the closing date, but no final decisions 
will be made until after the closing date. The 
starting date is flexible. 

The University of Illinois is an Affirmative 
Action/Equal Opportunity Employer. 


THE UNIVERSITY OF TRONDHEIM 
THE NORWEGIAN INSTITUTE 
OF TECHNOLOGY 

Department of Electrical Engineering 
and Computer Science 

The Department of Electrical Engineering 
and Computer Science has three full-time 
faculty positions available at the full professor 
level. The areas of specialization are systems 
software, computer architecture and knowl¬ 
edge technology. 

For all three positions a Ph.D. in the rele¬ 
vant area is required, with evidence of strong 
research accomplishment or potential. Interest 
and ability in teaching graduates and under¬ 
graduates is necessary. The appointed profes¬ 
sors will be expected to participate in the exter¬ 
nally funded research activities of the depart¬ 
ment. The computer equipment is mainly PC 
and UNIX workstations (SUNs and VAXes). 

The Norwegian Institute of Technology has 
5600 students and is part of the University of 
Trondheim. With the associated SINTEF 
research organization, teaching and research 
staff in the field of information technology 
number approx. 300 scientists. The city of 
Trondheim has 135000 inhabitants. There 
are good state schools in the area, also an 
English primary school. English is widely 
spoken, both at the Institute and in the com¬ 
munity. There are excellent opportunities for 
outdoor activity in the vicinity including skiing, 
fishing, hiking and cycling. 

Applications close on 15 September 1988. 

Further information about the positions and 
the teaching programme may be obtained by 
contacting Professor Peder J. Emstad, tele¬ 
phone + 47 7 594326, electronic mail 
emstad vax.elab.unit.uninett tor. nta.no at the 
Division of Computer Systems and Tele- 

Application, with certificates of education 
and information of previous work, should be 
addressed to the King of Norway and mailed 
to University of Trondheim, The Norwegian 
Institute of Technology, Personell Section, 
N-7034 Trondheim, Norway. 


CENTRE DE RECHERCHE 
INFORMATIQUE DE MONTREAL 
Researcher - Design of Reliable 
VLSI Circuits. 

CRIM is seeking a researcher to work with 
its team in the design of reliable VLSI circuits. 
This is a one year position with possibility of 
renewal. The successful candidate will also be 
offered a link with one of CRIM’s member 
universities. This link involves the supervision 
of graduate students and the teaching of one 
or two courses per year. Candidates must 
have an earned doctorate with research ex¬ 
pertise relevant to the interest of the team. 
Candidates must be also fluent in French or 
willing to learn. 

Work in VLSI is directed towards symbolic 
design and design automation, design verifi- 
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cation, testing, concurrent detection and fault 
tolerant computing. 

In accordance with Canadian immigration 
regulations, this advertisement is directed in 
the first instance to Canadian citizens and per¬ 
manent residents of Canada. If no suitable 
candidates are found, the search will be ex¬ 
tended to include other candidates. 

Applicants should send, under reference 
number ES8803A-AS, a resume, a list of 
publications and three references to Dr. Jac¬ 
queline Bourdeau, Assistant Director of Sci¬ 
entific Research at: 

Centre de recherche informatique 
de Montreal (CRIM) 

1550 de Maisonneuve Blvd. West 
Suite 1000 

Montreal, Quebec CANADA 
H3G 1N2 


UNIVERSITY OF NEBRASKA-UNCOLN 
Computer Science and 
Engineering Department 
Department Chair 

Applications and nominations are invited 
for a chairperson to lead a dynamic depart¬ 
ment that includes 13 doctorate faculty and 
offers programs leading to the BS, MS, and 
Ph.D. degrees. 

The department has strong research pro¬ 
grams in algorithms, theoretical computer 
science, communications theory and net¬ 
works, information retrieval, fault tolerant 
computing, and human factors. In addition, 
the university has a wide variety of computing 
resources linked by a sophisticated campus¬ 
wide network. UNL is the lead institution in 
the NSF-funded regional network, MIDnet, 
and a node on the NSFnet backbone. The 
State of Nebraska has recently appropriated 
special funds to enhance research in computer 
science. The incoming chairperson will play a 
fundamental role in the administration of 
these funds and associated new programs. 

Qualifications require earned Doctorate in 
computer science or related field, strong 
leadership for research and academic pro¬ 
grams, and credentials appropriate for ap¬ 
pointment as a full professor. Administrative 
experience is desirable. 

The starting date for this appointment is 
open. The closing date is September 1, 1988 
or until the position is filled. Salary will be 
commensurate with qualifications. Women 
and minorities are particularly encouraged to 
apply. 

Qualified applicants should send resumes 
and names of three references to: Prof. 
Spyros S. Magliveras, Chairman, Search 
Committee, Computer Science and Engi¬ 
neering Department, Ferguson Hall, Universi¬ 
ty of Nebraska, Lincoln, NE 68588-0115. 
E-mail address: spyros@fergvax.unl.edu. 

Affirmative Action/Equal Opportunity 
Employer. 
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ADVANCED TECHNOLOGIES 

U S WEST Advanced Technologies is the research and development 
organization within Fortune 50 ranked U S WEST. The Division of Science and 
Technology, engaged in applied research in emerging technologies, faces broad 
challenges in many areas. Candidates are sought in the area of software 
technology for the positions of 

MEMBER OF TECHNICAL STAFF 
TECHNICAL DIRECTOR 
POST-DOCTORAL FELLOW 

Group members are responsible for exploring novel approaches to improve the 
efficiency and quality of software development. The current emphasis is on the 
use of object-oriented database management systems and languages to provide 
advanced environments for software engineering, rapid prototyping, and design 
support. The target hardware is networked workstations. The technologies will 
be applied to a wide range of software problems in the telecommunications 
industry. 

Qualifications include a Ph.D. in Computer Science or a related field, or a M.S. 
with experience. Expertise in any of these areas is desirable: object-oriented 
databases or languages, rapid prototyping, visual programming, software 
engineering, expert system application in software engineering. A record of 
achievement in implementation or publication in related areas is a plus. 

U S WEST Advanced Technologies is an equal opportunity employer with 
highly competitive compensation packages, including: salary, performance 
bonuses, tuition assistance and flexible benefits. 


QUALIFIED CANDIDATES should send a resume and salary requirements to: 
U S WEST Advanced Technologies, 6200 S. Quebec St., Suite 340, Englewood 
CO 80111. REF#TJST6. 


Moving? 

PLEASE NOTIFY 
US 4 WEEKS 
IN ADVANCE 

IEEE Service Center 
445 Hoes Lane 
Piscataway, NJ 08854 


ATTACH • This notice of address 
LABEL change will apply to all 
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Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, EL 33733; 
(813) 864-8272; Compmail, e.gallizzi 


Three invited computer-graphics application 
papers to be featured at SIGGraph 88 


A paper entitled “A Hand Biomechan¬ 
ics Workstation” explaining the use of 
computer graphics for surgery planning 
and showing how it is useful in recon¬ 
structing the hands of children with 
leprosy will be one of three invited 
papers presented this summer at SIG¬ 
Graph 88. 

The 15th Conference on Computer 
Graphics and Interactive Techniques is 
slated for Atlanta August 1-5, spon¬ 
sored by the ACM in cooperation with 
the Computer Society’s Technical Com¬ 
mittee on Computer Graphics. The con¬ 
ference is co-chaired by Andrew Goodrich 
of the University of Michigan and Adele 
Newton of the University of Waterloo. 

The invited-paper session is an exper¬ 
iment at this year’s SIGGraph, which 
has a theme of “Unearth the World of 
Computer Graphics.” The other invited 
papers are entitled “Getting Graphics in 
Gear: Graphics and Dynamics in Driv¬ 
ing Simulation” and “Applications of 
Computer Graphics to the Visualization 
of Meteorological Data.” 

“A central theme to all these applica¬ 
tions is that they are examples in which 
good graphics are critical to the success 
of the application,” said John Dill of 
Microtel Pacific Research, who serves 
as technical program chair. 

The chair of the session, Hank Chris¬ 
tiansen of Brigham Young University, 
said hand biomechanics technology is 
particularly used for children who have 
lost hand functions from deterioration 
caused by leprosy. 

“The technology allows you to max¬ 
imize the use of the remaining ligaments 
by letting you see the kinematics—the 
possible motion,” Christiansen said. 

The presenters will also discuss re¬ 
attaching ligaments and will describe 
how computer graphics help them study 
what kind of motion will be possible in 
a reconstructed hand. With good graphics, 
researchers can visually learn how ten¬ 
dons and muscles push and pull and 
predict the capabilities of the recon¬ 
structed hand. 

The driving-simulation paper presents 
a solution to the need for mathematical 
modeling of complex nonlinear dynamics 
in real time. It involves building a 


domed platform big enough to support 
a car surrounded by screens and projec¬ 
tors providing a 180-degree field of 

“In the simulator, you can pretend 
you’re driving down the autobahn at 
150 miles per hour and you wouldn’t be 
able to tell the difference between this 
experience and driving a real car,” said 
lead author Rod Deyo of Evans and 
Sutherland. 

“It’s so realistic that we feel a test 
driver couldn’t tell it was a simulator,” 
said Deyo, adding that the system can 
be used for design and analysis as well 
as for testing dangerous situations with¬ 
out any danger to the operator. 

The third paper describes how com¬ 
puter graphics plays an important role 
in understanding meteorological data. 

“We’ll show some spectacular exam¬ 
ples of the ways computer graphics 
enhance data gleaned from satellites,” 
said lead author Thomas Papathomas 
of AT&T Bell Laboratories. 

“We can show a hurricane at multi¬ 
ple altitudes using depth and motion 
cues, portray the evolution of a thun¬ 
derstorm, or show the 3D nature of 
clouds,” Papathomas said. “What we 
see on the evening television weather 
report is years behind what’s being done 
at the leading research centers.” 

Also on the SIGGraph agenda are 11 
other technical paper presentations 
featuring computer graphics hardware 
and software innovations and new 
applications; technical panel sessions by 
researchers responsible for new and sig¬ 
nificant advances; 28 full-day educa¬ 
tional courses; a film and video show; 
an art show; a newcomers’ seminar; an 
educators workshop; and an exhibit of 
over 1,000 products featuring $30 mil¬ 
lion in equipment. 

Dill said he believes the papers that 
will attract the most attention are those 
devoted to volume rendering, physically 
based modeling, and lighting models. 
“There is also a returning interest in 
hardware that reflects the surging 
interest in visualization,” said Dill, 
adding that such visualization needs 
high-power graphics. 


July 1988 


Second Conference on Software Engineering 
(IEE, BCS), July 11-15, Liverpool, England. 
Contact Conference Services, IEE, Savoy 
Place, London WC2R OBL, England, UK. 

® CASE 88, Second International Work¬ 
shop on Computer-Aided Software 
Engineering (ACM), July 12-15, Cambridge, 
Mass. Contact Elliott Chikofsky, CASE 88, 
c/o Index Technology Corp., One Main St., 
Cambridge, MA 02142, phone (617) 
494-8200, ext. 552. 

12th IMACS World Congress on Scientific 
Computation, July 18-22, Paris. Contact 
Jean-Marc David, Laboratoires de Marcous- 
sis, Computer Science Division, Route de 
Nozay, 91460 Marcoussis, France. 


/£3^i Second Workshop on Software Test- 
N5? ing, Verification, and Analysis (ACM), 
July 19-21, Banff, Canada. Contact Lee 
White, Dept, of Computer Science, Univer¬ 
sity of Alberta, Edmonton, Alberta, Canada 
T6G 2H1, phone (403) 432-4589. 


PPEALS 88, Symposium on Parallel Pro¬ 
gramming: Experience with Applications, 
Languages, and Systems (ACM), July 19-21, 

New Haven, Conn. Contact Assoc, of Com¬ 
puting Machinery, 11 W. 42nd St., New 
York, NY 10036, phone (212) 869-7440. 


International Workshop on VLSI for Artifi¬ 
cial Intelligence, July 20-22, Oxford, 
England. Contact Jose G. Delgado-Frias or 
Will R. Moore, Dept, of Engineering 
Science, University of Oxford, Parks Rd., 
Oxford, OX1 3PJ, England, UK, phone 44 
(65) 27-31-88. 


ICNN 88, IEEE 1988 International Confer¬ 
ence on Neural Networks, July 24-27, San 
Diego, Calif. Contact Nomi Feldman, IEEE 
ICNN 88, 3770 Tansy St., San Diego, CA 
92121, phone (619) 453-6222. 

ECCE 88, European Conference on Com¬ 
puters and Education, July 24-29, Lausanne, 
Switzerland. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 


Summer Computer Simulation Conference 
(SCS), July 25-27, Seattle. Contact Society 
for Computer Simulation, PO Box 17900, 
San Diego, CA 92117, phone (619) 277-3888. 

Navy Micro/OA 88 Conference, July 25-28, 
San Diego, Calif. Contact Code 31.4, 
NARDAC San Diego, NAS North Island, 
Bldg. 1482, San Diego, CA 92135-5110, 
phone (619) 437-7013. 
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International Computers in Engineering 
Conference and Exhibition (ASME), July 
31-Aug. 3, San Francisco. Contact ASME 
Meetings Dept., 345 E. 47th St., New York, 
NY 10017, phone (212) 705-7788. 


R. Eugene Stuffle, Dept, of Electrical 
Engineering, 317 Engineering Research 
Laboratory, University of Missouri, Rolla, 
MO 65401-0249, phone (314) 341-4371. 


August 1988 


ZZX SIGGraph 88, 15th Conference and 
Exhibition on Computer Graphics and 
Interactive Techniques (ACM), Aug. 1-5, 

Atlanta. Contact Adele Newton, University 
of Waterloo, Dept, of Computer Science, 
Waterloo, Ontario, Canada N2L 3G1, phone 
(519) 888-4534. 


1988 International Computers in Engineering 
Conference (ASME), Aug. 7-11, San Fran¬ 
cisco. Contact Edward M. Patton, US Army 
Ballistic Research Lab, Aberdeen Proving 
Grounds, MD 21005. 


International Workshop on Protocol 
Test Systems (Vancouver Section of 
the Computer Society), Oct. 12-14, Vancou¬ 
ver, Canada. Contact Samuel Chanson or 
Son Vuong, Dept, of Computer Science, 
University of British Columbia, Vancouver, 
BC, Canada V6T 1W5, phone (604) 228-6667 
(for Chanson) or (604) 228-6366 (for 
Vuong). 


Joint Fifth Symposium and Fifth Inter- 
’55' national Conference on Logic Pro¬ 
gramming (Assoc, for Logic Programming), 
Aug. 15-19, Seattle. Contact Kenneth A. 
Bowen, Logic Programming Research 
Group, School of Computer and Informa¬ 
tion Science, 313 Link Hall, Syracuse Uni¬ 
versity, Syracuse, NY 13210, phone (315) 
423-2466 or 67. 


Structured Development Forum X 
(Lawrence Livermore National Laboratory), 
Aug. 8-11, San Francisco. Contact Ted 
Michels, LLNL, PO Box 808, L-308, Liver¬ 
more, CA 94550, phone (415) 423-4660. 

Third International Conference on Applica¬ 
tions of Artificial Intelligence in Engineer¬ 
ing, Aug. 8-12, Stanford, Calif. Contact R. 
Adey, Computational Mechanics Institute, 
25 Bridge St., Billerica, MA 01821, phone 
(617) 667-7582. 

American Mathematical Society Conference 
and Centennial Celebration, Aug. 8-12, 

Providence, R.I. Contact AMS, PO Box 
6248, Providence, RI 02940, phone (401) 
272-9500. 


ICPP 17, 17th International Conference on 
Parallel Processing, Aug. 15-19, St. Charles, 
Ill. Contact David H. Bailey, MS 258-5, 
NASA Ames Research Center, Moffett 
Field, CA 94035; Howard E. Sturgis, Xerox 
Corp., Palo Alto Research Center, 3333 
Coyote Hill Rd„ Palo Alto, CA 94304; or 
Faye A. Briggs, Sun Microsystems, 2550 
Garcia Ave., Mountain View, CA 94043. 

DIAC 88, Directions and Implications of 
Advanced Computing Symposium (CPSR), 
Aug. 21, St. Paul, Minn. Contact Doug 
Schuler, Computer Professionals for Social 
Responsibility, PO Box 717, Palo Alto, CA 
94301, phone (206) 865-3226. 


Seventh Conference of the Molecular 
Graphics Society, Aug. 10-12, San Fran¬ 
cisco. Contact Molecular Graphics Confer¬ 
ence Office, 16951 Pacific Coast Hwy., PO 
Box 385, Sunset Beach, CA 90742, phone 
(213) 592-1382. 

31st Midwest Symposium on Circuits and 
Systems, Aug. 11-12, St. Louis, Mo. Contact 


Crypto 88 (IACR), Aug. 21-25, Santa 
Barbara, Calif. Contact Harold 
Fredricksen, Mathematics Dept., Code 53Fs, 
Naval Postgraduate School, Monterey, CA 
93943, phone (408) 646-2206. 

AAAI 88, Seventh National Conference on 
Artificial Intelligence (AAAI), Aug. 21-26, 

St. Paul, Minn. Contact American Assoc. 


© Conferences that the Computer Society sponsors or participates ir 
by the Computer Society logo; additional conference sponsors are 
theses. Other conferences of interest to our readers are also included. 


are indicated 
listed in paren- 


For inclusion in Call for Papers or Calendar, submit information six weeks before the 
month of publication (i.e., for the September 1988 issue, send information for receipt 
by July 15,1988) to Calendar Editor, Computer , 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720. 


for Artificial Intelligence, 445 Burgess Dr., 
Menlo Park, CA 94025, phone (415) 
328-3123. 


CAD/CAM Technology Transfer to Latin 
America Conference (IFIP), Aug. 22-26, 

Mexico City. Contact G. Leon Lastra, Insti¬ 
tute de Investigaciones Electricas, Apdo. 
Postal 5-849, 11590 Mexico, D.F., phone 52 
(73) 129-632. 

Coling 88, 12th International Conference on 
Computational Linguistics, Aug. 22-27, 

Budapest, Hungary. Contact Coling 88 
Secretariat, Mtesz Congress Bureau, H-1055 
Budapest, Kossuth ter. 6-8, Hungary. 


z£ji| LFA 88, Sixth IEEE Workshop on 
Languages for Automation, Aug. 
29-31, College Park, Md. Contact Panos A. 
Ligomenides, Cybernetics Research Labora¬ 
tory, Electrical Engineering Dept., Univer¬ 
sity of Maryland, College Park, MD 20742, 
phone (301) 454-6842. 


International Forum on Increasing Manage¬ 
ment Productivity with Intelligent Systems, 
Aug. 29-31, Snowmass-Aspen, Colo. Con¬ 
tact Center for Applied Artificial Intelli¬ 
gence, College of Business and Administration, 
University of Colorado, Campus Box 419, 
Boulder, CO 80309, phone (303) 492-8229. 


14th International Conference on Very 
Large Databases (VLDB Endowment), 
Aug. 29-Sept. 1, Los Angeles. Contact Jack 
E. Shemer, Teradata Corp., 12945 Jefferson 
Blvd., Los Angeles, CA 90066, phone (213) 
827-8777. 

EuroMicro 88, 14th Symposium on 
Microprocessing and Microprogramming, 
Aug. 29-Sept. 1, Zurich. Contact EuroMicro 
88, PO Box 545, 7500 AM Enschede, The 
Netherlands, phone 31 (53) 33-87-99. 

International Conference on Computer Pro¬ 
cessing of Chinese and Oriental Languages, 
Aug. 29-Sept. 1, Toronto, Canada. Contact 
C.N. Liu, IBM T.J. Watson Research Cen¬ 
ter, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 789-7531. 


ICO Topical Meeting on Optical Com- 
puling, Aug. 30-Sept. 2, Orsay, 

France. Contact S. Lowenthal, Insitut D’Up- 
tique, BP 43, 91406 Orsay Cedex, France. 

ITC 88, 1988 International Test Con- 
ference, Aug. 30-Sept. 2, Washington, 
DC. Contact ITC 88, Computer Society, 

1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 
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September 1988 

^3^ International Neural Network Society 
^*7 Conference (INNS), Sept. 6-10, Bos¬ 
ton. Contact Mark Kon, Dept, of Mathematics, 
Boston University, 111 Cummington St., 
Boston, MA 02115, phone (617) 353-2762; or 
INNS Conference, J.R. Schuman Associ¬ 
ates, PO Box 125, 316 Washington St., 
Wellesley, MA 02181, phone (617) 237-7931. 

£3^ 1988 International Test Conference, 
Sept. 12-14, Washington, DC. Contact 
Doris Thomas, ITC, PO Box 264, Mt. Free¬ 
dom, NJ 07970, phone (201) 895-5260. 

NCGA Mapping and Geographic Informa¬ 
tion Systems 88, Sept. 12-15, Orlando, Fla. 
Contact NCGA, National Computer 
Graphics Assoc., 2722 Merrilee Dr., Suite 
200, Fairfax, VA 22031. 

Eurographics 88, Ninth European Assoc, for 
Computer Graphics Conference (INRIA), 
Sept. 12-16, Nice, France. Contact INRIA, 
Service des Relations Exterieures, Domaine 
de Voluceau, BP 105, 78153 Le Chesnay 
Cedex, France, phone 33 (1) 39-63-55-01. 

Fourth International Conference of 
^5? Modeling Techniques and Tools for 
Computer Performance Evaluation (UIB, 
ATI), Sept. 15-17, Palma de Mallorca, 

Spain. Contact Ramon Puigjaner, UIB, 
Miguel dels Sants Oliver 2, 07012 Palma de 
Mallorca, Spain, phone 34 (71) 72-57-06. 

/gjv IEEE Artificial Neural Networks Con- 
v*? ference, Sept. 18-21, Reston, Va. Con¬ 
tact Kamal Karma, 823 Flegler Rd., 
Gaithersburg, MD 20879, phone (301) 
984-7657. 

Fourth International Symposium on Biologi¬ 
cal and Artificial Intelligence Systems, Sept. 

18- 22, Trento, Italy. Contact Alberta Mar¬ 
tino, IBM Corp., Dept. 48B/428, Neighbor¬ 
hood Rd., Kingston, NY 12401, phone (914) 
385-4964. 

Sixth Software Quality Conference (Pacific 
Northwest Software Quality Conference 
Committee), Sept. 19-20, Portland, Ore. 
Contact Mary Lawrence, Lawrence & Craig, 
320 SW Stark, Rm. 411, Portland, OR 
97204, phone (503) 222-2606. 

Conference on Computerized Assistance 
During System Life Cycle (IFIP), Sept. 

19- 22, London. Contact International Feder¬ 
ation for Information Processing, 3 rue de 
Marche, CH-1204, Geneva, Switzerland. 

Workshop and Symposium on Formal Tech¬ 
niques in Real-time and Fault-tolerant Sys¬ 
tems, Sept. 20-23, Coventry, England. 
Contact M. Joseph, Dept, of Computer 
Science, University of Warwick, Coventry, 
CV4 7AL, UK. 

tgfjt First International Workshop on 
Transaction Machine Architecture, 

Sept. 25-28, Lake Arrowhead, Calif. Con¬ 
tact Martin Freeman, Signetics Corp., 811 E. 
Arques Ave., Sunnyvale, CA 94086, phone 
(408) 991-3591. 


OOPSLA 88 (ACM), Sept. 25-29, San 
Diego, Calif. Contact Barbara Noparstak, 
Digitalk, Inc., 9841 Airport Blvd, Los 
Angeles, CA 90045, phone (213) 645-1082. 

Computational Intelligence 88 (ACM), 
Sept. 26-30, Milan, Italy. Contact 
Giorgio Valle, Universita di Milano, Dip. di 
Sciencze dell’Informazione, Via Moretto 9, 
20133 Milano, Italy, phone 39 (2) 27-72-228. 

© Second International Workshop on 
Object-Oriented Programming Data¬ 
base Systems (GI, FZI, ACM), Sept. 27-30, 
Bad Muensteram Stein-Ebemburg, Ger¬ 
many. Contact Alex Buchmann, CCA, Four 
Cambridge Center, Cambridge, MA 02142, 
phone (617) 492-8860. 

26th Allerton Conference on Communica¬ 
tion, Control, and Computing, Sept. 28-30, 

Monticello, Ill. Contact Allerton Confer¬ 
ence, c/o Mark W. Spong, Coordinated 
Science Laboratory, University of Illinois at 
Urbana-Champaign, 1101 W. Springfield 
Ave., Urbana, IL 61801, phone (217) 
333-4281. 


October 1988 

ICCD 88, IEEE International Confer¬ 
va? ence on Computer Design, Oct. 2-6, 

Rye Brook, N.Y. Contact Prathima 
Agrawal, ICCD 88, AT&T Bell Laborato¬ 
ries, 600 Mountain Ave., Rm. 3D-480, Mur¬ 
ray Hill, NJ 07974, phone (201) 582-6943. 

EWSL 88, Third European Working Session 
on Learning, Oct. 3-5, Glasgow, Scotland. 
Contact Derek Sleeman, Dept, of Comput¬ 
ing Science, University of Aberdeen, Aber¬ 
deen AB9 2UB, Scotland, UK, phone 44 
(224) 27-22-88. 

Compsac 88, 12th International Com- 
puter Software and Applications Con¬ 
ference, Oct. 3-7, Chicago. Contact Wing N. 
Toy, Compsac 88, AT&T Bell Laboratories, 
Rm. 1Z-306, 200 Park Plaza, Naperville, IL 
60566, phone (312) 416-4046; or Computer 
Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

1988 International Display Research Confer¬ 
ence (IEEE, SID), Oct. 4-6, San Diego, 

Calif. Contact Palisades Institute for 
Research Services, Attn. IDRC, 201 Varick 
St., New York, NY 10014, phone (212) 
620-3388. 

Northcon 88 (IEEE, ERA, EMA), Oct. 4-6, 

Seattle. Contact Electronic Conventions 
Management, 8110 Airport Blvd., Los 
Angeles, CA 90045-3194, phone (213) 
772-2965. 

International Workshop on Defect and 
Fault Tolerance in VLSI Systems, Oct. 
6-7, Springfield, Mass. Contact Israel Koren, 
Dept, of Electrical and Computer Engineer¬ 
ing, University of Massachusetts, Amherst, 
MA 01003, phone (413) 545-2643. 


NCGA CAD/CAM 88, Oct. 9-12, Boston. 
Contact NCGA CAD/CAM 88, National 
Computer Graphics Assoc., 2722 Merrilee 
Dr., Suite 200, Fairfax, VA 22031. 

Z3^ ICCL 88, International Conference on 
Computer Languages, Oct. 9-13, 

Miami Beach, Fla. Contact Pei Hsia, Com¬ 
puter Science Engineering Dept., University 
of Texas, 2100 Oak Bluff Dr., Arlington, 
TX 76019, phone (817) 273-3610. 

Seventh Symposium on Reliable Dis- 
V*? tributed Systems, Oct. 10-12, 

Columbus, Ohio. Contact David Cohen, 
Tekuekron Infoswitch, 1784 Firman Dr., 
Richardson, TX 75081; or Ming T. Liu, 
Dept, of Computer and Information 
Science, Ohio State University, 2036 Neil 
Ave., Columbus, OH 43210-1277, phone 
(614)292-1837. 

^3^v 1988 IEEE Workshop on Visual Lan- 
Vs? guages, Oct. 10-12, Pittsburgh. Con¬ 
tact A.T. Berztiss, Dept, of Computer 
Science, University of Pittsburgh, Pitts¬ 
burgh, PA 15260. 

£3^ 13th Conference on Local Computer 
vl? Networks, Oct. 10-12, Minneapolis, 
Minn. Contact Ron Rutledge, MS-271, Mar¬ 
tin Marietta Energy Systems, Oak Ridge 
National Laboratory, Oak Ridge, TN 37831, 
phone (615) 576-7643. 

£3^1 Frontiers 88, Second Symposium on 
Va? the Frontiers of Massively Parallel 
Computation, Oct. 10-12, Fairfax, Va. Con¬ 
tact James R. Fischer, Frontiers 88 Sympo¬ 
sium, Code 635, NASA Goddard Space 
Flight Center, Greenbelt, MD 20771, phone, 
(301) 286-3464. 

International Workshop on Computer 
Vision (IAPR), Oct. 12-14, Tokyo. Contact 
Mikio Takagi, Institute of Industrial 
Science, University of Tokyo, 7-22-1, Rop- 
pongi, Minato-ku, Tokyo 106, Japan, phone 
81 (3) 479-0289. 

ACM SIGGraph Symposium on User Inter¬ 
face Software, Oct. 17-19, Banff, Canada. 
Contact John Sibert, Dept, of Electrical 
Engineering and Computer Science, George 
Washington University, Washington, DC 
20052, phone (202) 994-4953. 

/£3^j ESIG 88, Fourth Expert Systems in 
Va? Government Conference, Oct. 17-21, 

Washington, DC. Contact ESIG 88, MS 
W418, Mitre Corp., 7525 Colshire Dr., 
McLean, VA 22102; or Computer Society, 
1730 Massachusetts Ave. NW, 20036-1903, 
phone (202) 371-1013. 

Third International Symposium on Knowl¬ 
edge Engineering (AAAI), Oct. 17-21, 
Madrid, Spain. Contact Jose R. Chelala, 
Third International Symposium on Knowl¬ 
edge Engineering, Alvarez de Baena, 3-2, 
28006 Madrid, Spain. 

Fourth Software Engineering Conference 
and Exhibition (AFCET), Oct. 18-21, Paris. 
Contact CGL4, 156 blvd. Pereire, 75017 
Paris, France. 
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1988 Concom, Advances in Communications 
and Control Systems, Oct. 19-20, Baton 
Rouge, La. Contact Morteza Naraghi-Pour, 
Dept, of Electrical and Computer Engineer¬ 
ing, Louisiana State University, Baton 
Rouge, LA 70803, phone (504) 388-5551. 

29th Foundations of Computer Science 
'549 (FOCS), Oct. 24-26, White Plains, 
N.Y. Contact Christos Papadimitrou, 
Department of Computer Science and 
Engineering, University of California at San 
Diego, La Jolla, CA 92043, phone (619) 
534-2086. 


CSM 88, Conference on Software 

'549 Maintenance-1988 (DPMA), Oct. 
24-27, Phoenix, Ariz. Contact Robert 
Arnold, Software Productivity Consortium, 
1880 Campus Commons Dr. North, Reston, 
VA 22091, phone (703) 391-1898. 


First International Symposium on Artificial 
Intelligence, Oct. 24-28, Monterrey N.L., 
Mexico. Contact Francisco J. Cantu, Insti¬ 
tute Tecnologico de Monterrey, ITESM 
Sue. Correos “J”, Monterrey N.L., Mexico, 
64849, phone 52 (83) 59-59-43. 


ZSL, Second International Software for 
v49 Strategic Systems Conference, Oct. 
25-26, Huntsville, Ala. Contact Karen B. 
Mack, University of Alabama, Division of 
Continuing Education, Tom Bevill Center, 
Huntsville, AL 35899, phone (205) 895-6357. 


IECON 88 (IEEE), Oct. 25-27, Singapore. 
Contact V.K.L. Huang, AT&T Information 
Systems, Crawford Corners Rd., Holmdel, 
NJ 07733, phone (210) 949-0069. 


Systec 88, Second International Trade Fair 
for Computer-Integrated Manufacturing, 
Oct. 25-28, Munich, West Germany. Contact 
Munchener Messe- und Ausstellungsgesell- 
schaft mbH, Projektleitung Systec 88, Post- 
fach 12 10 09, D-8000 Munchen 12, West 
Germany, phone 49 (89) 51-070. 


Ninth IEEE Symposium on Mass Storage 
Systems, Oct. 30-Nov. 3, Monterey, Calif. 
Contact Patric Savage, Shell Development 
Co., PO Box 481, Houston, TX 77001, 
phone (713) 663-2384. 

ICCC 88, Ninth International Conference on 
Computer Communication (IEEE Israel Sec¬ 
tion), Oct. 30-Nov. 3, Tel Aviv, Israel. Con¬ 
tact J. Kella, Secretariat, PO Box 50006, Tel 
Aviv 61500, Israel, phone 972 (3) 654-571. 

£2^> 22nd Asilomar Conference on Signals, 
v49 Systems, and Computers (IEEE, Naval 
Postgraduate School), Oct. 31-Nov. 2, 
Pacific Grove, Calif. Contact Douglas 
Elliott, Rockwell International, 3370 Mira- 
loma Ave., Mail Stop BD07, Anaheim, CA 
92803-317, phone (714) 762-2340. 

ICCS 88, International Conference on Com¬ 
munication Systems (IEEE), Oct. 31-Nov. 3, 
Singapore. Contact ICCS 88, c/o Meeting 
Planners Pte Ltd., 100 Beach Rd., #33-04, 
Shaw Towers, Singapore 0718. 


November 1988 

1988 Workshop on VLSI Signal Processing, 
Nov. 2-4, Monterey, Calif. Contact Paulette 
Powell, Electronics Research Laboratory, 
University of California, Berkeley, CA 
94720, phone (415) 642-1566. 

Symposium on Computer Graphics Educa¬ 
tion, Nov. 4-5, Poughkeepsie, N.Y. Contact 
Deborah Coleman, West Coast University, 
440 Shatto PL, Los Angeles, CA 90020; or 
William J. Joel, Marist College, 82 North 
Rd., Poughkeepsie, NY 12601. 

12th Symposium on Computer Applications 
in Medical Care, Nov. 6-9, Washington, DC. 
Contact Office of Continuing Medical Edu¬ 
cation, George Washington University Medi¬ 
cal Center, 2300 K St. NW, Washington, DC 
20037, phone (202) 994-8928. 

ICCAD 88, IEEE International Con- 
*54? ference on Computer-Aided Design 
(ACM) Nov. 7-10, Santa Clara, Calif. Con¬ 
tact A1 Jimenez, Mentor Graphics Corp., 
1940 Zanker Rd., San Jose, CA 95112, 
phone (408) 436-1500; or Pro CASE, 3130 
Dela Cruz Blvd., Suite 100, Santa Clara, CA 
95054, phone (408) 727-0714. 

Third Workshop on Knowledge Acquisition 
for Knowledge-Based Systems (AAAI), Nov. 
7-11, Banff, Canada. Contact John H. 


Boose, Advanced Technology Center, Boe¬ 
ing Computer Services, MS 7L-64, PO Box 
24346, Seattle, WA 98124, phone (206) 
865-3253. 

GOMAC 88, Government Microcircuit 
Applications Conference, Nov. 8-10, Las 
Vegas, Nev. Contact C. Edward Holland, 
Jr., Semiconductor Research Corp., 4501 
Alexander Dr., PO Box 12053, Research Tri¬ 
angle Park, NC 27709, phone (919) 

541-9400. 

1988 IEEE Nuclear Science Symposium and 
Symposium on Nuclear Power Systems, 

Nov. 9-11, Orlando, Fla. Contact E. Bar- 
sotti, Fermilab, MS 222, Box 500, Batavia, 
IL 60510, phone (312) 840-4061. 

Second International Symposium on 
Interoperable Information Systems 
(INTAP), Nov. 10-11, Tokyo. Contact 
Hideo Aiso, Dept, of Electrical Engineering, 
Keio University, 3-14-1, Hiyoshi, Kohoku- 
ku, Yokohama, Karagawa, 223 Japan, 
phone 81 (44) 63-1141, ext. 3320. 

Ninth International Conference on Pattern 
Recognition (IAPR), Nov. 14-17, Rome. 
Contact M.J.B. Duff, Dept, of Physics and 
Astronomy, University College London, 
Gower St., London WC1E 6BT, England, 
UK, phone 44 (1) 380-7010; Herbert Free¬ 
man, CAIP Center, Rutgers University, Pis- 
cataway, NJ 08855-1390, phone (201) 


Computer Scientists 
Software Engineers 

The Scientific Software Division at the Lawrence Livermore National 
Laboratory is seeking highly motivated individuals to work on state- 
of-the-art, fast-paced scientific projects in an R&D environment. Re¬ 
quirements include a BS, MS, or PhD degree in Computer Science, 
Computer Engineering, or equivalent experience, and a minimum 
of two years’ software development experience in a technical en¬ 
vironment. 

Positions in CAD, image processing, signal processing, computer 
graphics, simulation, real-time data acquisition and digital con¬ 
trol, and real-time operating system development are available for 
those with SUN, ‘C’, and UNIX, VAX/VMS, or VAX/ELN experience. 
Senior level technical management positions are also available. 

Positions in international data communications and software 
quality assurance are available for those with experience in these 
areas. 

Please send resumes to. Scientific Software Division, Lawrence 
Livermore National Laboratory, P.O. Box 808, L-307, Dept. 
KCS71803B, Livermore, CA 94550. U S. citizenship required. An 
equal opportunity employer. 

University of California 

III Lawrence Livermore 
l!r National Laboratory 


July 1988 






932-3443; or Stefano Levialdi, Dipartimento 
di Matematica, Universita di Roma, Piazzale 
Aldo Moro 2,1-00185 Roma, Italy, phone 39 
(6) 49-91-32-49 or 50. 


j£j^! Supercomputing 88 (ACM), Nov. 

14-18, Kissimmee, Fla. Contact George 
Michael, Lawrence Livermore National 
Laboratory, PO Box 808, L-306, Livermore, 
CA 94550, phone (415) 422-4239. 


Seventh International Conference on 
^7 Entity-Relationship Approach (ERI), 
Nov. 14-18, Rome. Contact Salvatore T. 
March, Management Sciences, University of 
Minnesota, 271 19th Ave. South, Min¬ 
neapolis, MN 55455, phone (612) 624-2017. 


Fourth Conference on Artificial Intelligence 
for Space Applications (NASA), Nov. 15-16, 

Huntsville, Ala. Contact Conference on 
Artificial Intelligence for Space Applica¬ 
tions, NASA/EB44, MSFC, AL 35812, 
phone (205) 544-5181. 


AIDA 88, Fourth Conference on Artificial 
Intelligence and Ada, Nov. 15-16, Washing¬ 
ton, DC. Contact Jorge Diaz-Herrera, Com¬ 
puter Science Dept., George Mason 
University, 400 University Dr., Fairfax, VA 
22030, phone (703) 323-2713. 


Sixth CIPS Edmonton Computer Confer¬ 
ence, Nov. 15-17, Edmonton, Canada. Con¬ 
tact U.M. Maydell, Dept, of Computing 
Science, University of Alberta, Edmonton, 
Alberta, T6G 2H1, Canada. 


Wescon 88 (IEEE), Nov. 15-17, Anaheim, 
Calif. Contact Wescon 88, c/o Electronic 
Conventions Management Educational 
Activities Dept., 8110 Airport Blvd., Los 
Angeles, CA 90045, phone (213) 772-2965. 


12th Western Educational Computing Con¬ 
ference (California Educational Computing 
Consortium), Nov. 17-18, San Diego, Calif. 
Contact Judah Rosenwald, Extended Educa¬ 
tion, NAD 153, San Francisco State Univer¬ 
sity, 1600 Holloway, San Francisco, CA 
94132, phone (415)338-1212. 


Micro 21, Workshop on Micropro- 
V37 gramming and Microarchitecture 
(ACM), Nov. 28-Dec. 1, San Diego, Calif. 
Contact Wen-Mei Hwu, Coordinated 
Science Laboratory, University of Illinois at 
Urbana-Champaign, 1101 W. Springfield 
Ave., Urbana, IL 61801, phone (217) 
244-8270. 

tgjjt FGCS 88, International Conference on 
Fifth Generation Computer Systems 
(IPSJ), Nov. 28-Dec. 2, Tokyo. Contact 
Hideo Aiso, Dept, of Electrical Engineering, 
Keio University, 3-14-1, Hiyoshi, Kohoku- 
ku, Yokohama, Karagawa, 223 Japan, 
phone 81 (44) 63-1141, ext. 3320. 


December 1988 


IEEE Globecom 88, Dec. 1-2, Hollywood, 
Fla. Contact Dennis J. Sassa, Bell Commu¬ 


nications Research, NVC 2Z-129, 331 New¬ 
man Springs Rd„ Red Bank, NJ 07701-7020, 
phone (201) 446-6787. 


International Symposium on Databases 
for Parallel and Distributed Systems, 
Dec. 5-7, Austin, Texas. Contact Joseph E. 
Urban, Department of ECE, University of 
Miami, PO Box 248294, Coral Gables, FL 
33124, phone (305) 284-3598; or Won Kim, 
MCC, 3500 Balcones Center Dr., Austin, TX 
78759, phone (512) 338-3439. 


SIGSoft 88, Third Symposium on Software 
Development Environments (ACM), Dec. 
5-7, Boston. Contact Barry Boehm, TRW- 
DSG, One Space Park, R2-2086, Redondo 
Beach, CA 90278. 


Ninth Real-Time Systems Symposium, 
^57 Dec. 6-8, Huntsville, Ala. Contact 
Walter L. Heimerdinger, Honeywell, Sys¬ 
tems & Research Center, MN65-2100, 3660 
Technology Dr., Minneapolis, MN 55418, 
phone (612) 782-7319. 


EuroComm 88, Second International Exhibi¬ 
tion and Congress on Business, Public, and 
Home Communications, Dec. 6-9, Amster¬ 
dam. Contact H. Heringa, EuroComm 88, 
c/o RAI Gebouw bv, Europaplein, 1078 GZ 
Amsterdam, The Netherlands, phone 31 (20) 
549-1212. 


Application, University of Hong Kong, 
Hong Kong. 

ICS 88, 1988 International Computer Sym¬ 
posium, Dec. 20-21, Taipei, Taiwan. Con¬ 
tact Louis R. Chow, Tamkang University, 
Tamsui, Taiwan, Republic of China; or Shi- 
Kuo Chang, Dept, of Computer Science, 
University of Pittsburgh, Pittsburgh, PA 
15260. 

Eighth Conference on Foundations of Soft¬ 
ware Technology and Theoretical Computer 
Science, Dec. 21-23, Pune, India. Contact 
K.V. Nori, TRDDC, 1 Mangaldas Rd., Pune 
411001, India, phone 91 (212) 61-608. 

10th Israel Convention on CAD/CAM and 
Robotics, Dec. 27-29, Tel Aviv. Contact 
Secretariat, Ortra, Ltd., PO Box 50432, Tel 
Aviv 61500, Israel, phone 972 (3) 664-825. 


January 1989 


International Conference on Wafer 
Scale Integration, Jan. 3-5, San Fran¬ 
cisco. Contact Earl Swartzlander, TRW, 
R2/2076, One Space Park, Redondo Beach, 
CA 90278, phone (213) 812-0791. 


International Seminar on Performance of 
Distributed and Parallel Systems, Dec. 7-9, 
Kyoto, Japan. Contact Yutaka Takahashi, 
Dept, of Applied Mathematics and Physics, 
Kyoto University, Kyoto 606, Japan, phone 
81 (75) 751-2111, ext. 5513. 


22nd Hawaii International Conference 
on Systems Sciences, Jan. 3-6, Kailua- 
Kona, Hawaii. Contact Ralph Sprague, Jr., 
Decision Sciences Dept., University of 
Hawaii, 2404 Maile Way, E-303, Honolulu, 
HI 96822, phone (808) 948-7430. 


ICCV 88, Second International Con- 
vAz ference on Computer Vision, Dec. 
12-15, Tarpon Springs, Fla. Contact Ruzena 
Bajcsy, Computer and Information Science 
Dept., University of Pennsylvania, 200 S. 
33rd St., Philadelphia, PA 19104-6389, 
phone (215) 898-6222. 


j£3^| Fourth Aerospace Computer Security 
Applications Conference (ASIS, 
AIAA, DoD, ACSA), Dec. 12-16, Orlando, 
Fla. Contact Marshall Abrams, 1820 Dolley 
Madison Blvd., McLean, VA 22101, phone 
(703) 883-6938; or Robert D. Kovach, Aer¬ 
ospace Computer Security Associates, c/o 
ORI, 1375 Piccard Dr., Rockville, MD 
20850. 


Second International Workshop of VLSI 
Design (Computer Society of India), Dec. 
15-18, Bangalore, India. Contact Ravi M. 
Apte, Valid Logic Systems, 2820 Orchard 
Pkwy, San Jose, CA 95134, phone (408) 
432-9400; or A. Prabhakar, Indian Tele¬ 
phone Industries, Dooravani Nagar, Ban¬ 
galore 560 016, India, phone 91 (812) 
563-211. 


j£3^| 1988 International Computer Science 
va? Conference, Dec. 19-21, Hong Kong. 
Contact Jean-Louis Lassez, IBM T.J. Wat¬ 
son Research Center, PO Box 218, York- 
town Heights, NY 10598; or Francis Y.L. 
Chin, Center of Computer Studies and 


Impact of Recent Computer Advances on 
Operations Research (ORSA), Jan. 4-6, Wil¬ 
liamsburg, Va. Contact Ramesh Sharda, 
College of Business Administration, Okla¬ 
homa State University, Stillwater, OK 74078, 
phone (405) 624-5113. 


Second International Workshop on 
Artificial Intelligence in Economics 
and Management (IFIP, IFORS, IFAC) Jan. 
11-13, Singapore. Contact Juzar Motiwalla 
or Vicky Toh, Institute of Systems Science, 
National University of Singapore, Heng Mui 
Keng Terrace, Singapore 0511, phone (65) 
772-2075. 


February 1989 


1989 IEEE Aerospace Applications Confer¬ 
ence, Feb. 5-10, Breckenridge, Colo. Con¬ 
tact Leo Mallette, Hughes Aircraft, MS: 
Bldg. R-10, A9026, PO Box 92919, Los 
Angeles 90009, phone (213) 334-2909. 


,£3^s Fifth International Conference on 
Data Engineering Feb. 7-9, Los 

Angeles. Contact John Carlis, Computer 
Science Dept., University of Minnesota, 207 
Church St., SE, Minneapolis, MN 55455, 
phone (612) 625-6092; or Data Engineering 
89, Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 
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ASSOCIATION FOR COMPUTING MACHINERY 
1989 COMPUTER SCIENCE CONFERENCE® 

February 21 - 23, 1989 • The Galt House • Louisville, Kentucky 

Commonwealth Convention Center 


Conference chairman: Arthur M. Riehl, University of Louisville 
Louisville, Kentucky 40292 
(502)588-6306 


The 1989 ACM Computer Science Conference will focus 
on the emerging computing trends of the 1990’s. Emerging 
trends in three areas will provide the theme for the three 
days. Issues related to knowledge-based systems and paral¬ 
lel computing will be addressed by keynote speakers, re¬ 
search groups, and panels during the first and second days. 
These areas will be integrated on the third day for an in- 
depth examination of fifth generation hardware and 
software systems. In particular the influence of the Japanese 
Fifth Generation program will be the focus of several ac¬ 
tivities. 

Tutorials on the evening before each theme day will be in¬ 
cluded with the conference registration to provide non¬ 
specialists with sufficient background information so they 
may benefit from the theme day program. The tutorials will 
include terminology, a survey of the area, and a historical 
perspective for the participant 

Knowledged-Based Systems 

This theme day will focus on computing systems with em¬ 
bedded expertise. Areas such as expert databases, real-time 
expert systems, and distributed intelligence will continue to 
be areas of research interest in the 1990’s. 

Parallel Computing 

The second theme day will examine the new architectures 
that will be emerging in the 1990’s. The algorithms, operat¬ 
ing systems, and hardware will be much more complex and 
challenging to both designers and implementers. 

Looking to the Fifth Generation 

In cooperation with SIGCSE, the third theme day will blend 
current research topics with an emphasis on education. The 
impact of these new technologies on our profession and on 
training in our profession will be the focus. Educational ac¬ 
tivities in business and industry as well as academic 
programs must address the rapidly changing technologies 
of the 1990’s. 


CSC ’89 Call For Papers 

Papers are sought on topics including, but not limited to, the 
identified Conference focus. Papers are limited to ten pages 
and twenty minute presentations. Five copies of completed 
papers in format suitable for review must be received by 
September 1, 1988. Authors will be notified of review 
decisions by November 1,1988. Camera-ready form copy 
must be received by December 1,1988. 

CSC ’89 Call For Panels and Tutorials 

Panels and tutorials on current research topics are solicited. 
Sessions are normally limited to one hour. Five copies of 
overviews including proposed panelists and descriptions 
suitable for review are due September 1, 1988. Notifica¬ 
tion of review decisions will be given by November 1,1988. 
Overviews in camera-ready form must be received by 
December 1,1988. 

CSC ’89 Call For Abstracts 

Research abstracts and short reports are limited to a maxi¬ 
mum of 500 words and twelve minute presentations. 
Abstracts in camera-ready form must be received by 
November 15, 1988. Authors will be notified of review 
decisions by December 15,1988. 

All accepted materials will be published in the Conference 
Proceedings. 

Mail Papers, Proposals For Panels and 
Tutorials, And Abstracts To: 

1989 ACM COMPUTER SCIENCE CONFERENCE 

Dr. John McGregor 

Department of Computer Studies 

Murray State University 

Murray, Kentucky 42071 

(502) 762-6214 


The A.M. Turing Award will be presented at CSC ’89 to an individual selected for contributions of a 
technical nature to the computing community. The recipient will present a Turing Award Lecture at the 
conference. This is ACM’s most prestigious technical award and is accompanied by a prize of $25,000. 
It is presented in commemoration of Dr. A.M. Turing, an English mathematician who made many im¬ 
portant contributions to the field of computing. It has been presented since 1966. 









CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in 
several upcoming special issues. 

Rapid Prototyping will be the theme of 
the May 1989 issue. 

Suggested topics include 

• the role of knowledge engineering in 
prototyping environments; 

• rapid prototyping of real-time 
systems; 

• domain-specific rapid prototyping 
systems; 

• reusability in prototyping envi¬ 
ronments; 

• support tools for prototyping envi¬ 
ronments; 

• prototyping experience with ART, 
KEE, PC +, etc.; 

• prototyping experience with C + +, 
Smalltalk, Flavors Objective-C, 

Ada, etc.; and 

• prototyping experience with CASE 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript should be submitted by 
Sept. 1, 1988 to Murat M. Tanik, Com¬ 
puter Science and Engineering Depart¬ 


ment, Southern Methodist University, 
Dallas, TX 75275, phone (214) 692-2854, 
E-mail: smu.tanik@uunet.uu.net; or to 
Raymond T. Yeh, ISSI International, 
9420 Research Blvd., Suite 2000, Austin, 
TX 78759, phone (512) 338-1895, csnet: 
issi@emx.utexas.edu. 

Authors will be notified of acceptance by 
Dec. 1,1988. The final version of the 
manuscript is due no later than Jan. 1, 
1989. 

Persons interested in serving as referees 
are asked to send a note with a list of 
technical interests to Tanik or to Bruce 
D. Shriver, Computer Editor-in-Chief, 
Department of Decision Sciences, Uni¬ 
versity of Hawaii, 2404 Maile Way, 
Honolulu, HI 96822. 


Autonomous Intelligent Machines is the 

theme scheduled for the June 1989 issue. 

Suggested topics include 

• distributed and parallel architectures 
for intelligent machines; 

• multisensor integration for intelli¬ 
gent machine applications; 

• real-time control and coordination 
of mobile robots and manipulators; 

• machine intelligence and expert 
systems; 


• robot programming 

• path planning and navigation; and 

• learning and autonomous machines. 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript must be submitted by 
Oct. 1, 1988 to S. Sitharama Iyengar, 
Department of Computer Science, Loui¬ 
siana State University, Baton Rouge, LA 
70803-4020, phone (504) 388-1495, E- 
mail: iyengar%lsu.edu@relay.csnet; or 
to Rangasami L. Kashyap, Department 
of Electrical Engineering, Purdue Univer¬ 
sity, West Lafayette, IN 47907, phone 
(317) 494-3473, csnet E-mail address: 
kashyap@ee. ecn. purdue. edu. 


Authors will be notified of acceptance by 
Jan. 10, 1989. The final version of the 
manuscript is due no later than Feb. 25, 
1989. 

Persons interested in serving as referees 
are asked to send a note with a list of 
technical interests to Iyengar, Kashyap, 
or Bruce D. Shriver, Computer Editor-in- 
Chief, Department of Decision Sciences, 
University of Hawaii, 2404 Maile Way, 
Honolulu, HI 96822. 


£3^1 IEEE Workshop on Visual Motion: 

Mar. 20-22, 1989, Irvine, Calif. Submit 
paper by July 15, 1988 to Ellen Hildreth, 
Artificial Intelligence Laboratory, 545 Tech¬ 
nology Square, Cambridge, MA 02139; or 
Ramesh Jain, Electrical Engineering and 
Computer Science Dept., University of 
Michigan, Ann Arbor, MI 48109-2122. 

PCCC 89, Phoenix Conference on 
^87 Computers and Communications: 

Mar. 22-24, 1989, Scottsdale, Ariz. Submit 
paper by July 15, 1988 to one of the follow¬ 
ing: Frank Boesch, Chairman, EECS, 

Stevens Institute of Technology, Hoboken, 
NJ 07030 (for US East Coast authors); 
Dennis Allison, Computer Science Lab, 
ERL-444, Stanford University, Stanford, 

CA 94305 (for the US West Coast); Giulio 
Occhini, Honeywell Bull, Via Vida 11, 

Milan, Italy (for Europe); Richard Duke, 
Faculty of Engineering, University of Can¬ 
terbury, Private Bag, Christchurch, New 
Zealand (for Australia/New Zealand); or 
Makoto Nagao, Dept, of Electrical 
Engineering, Kyoto University, Kyoto, 

Japan (for Asia). 


26th Allerton Conference on Communica¬ 
tion, Control, and Computing: Sept. 28-30, 
1988, Monticello, Ill. Submit paper and 
extended abstract by July 15,1988 to Aller¬ 
ton Conference, c/o Mark W. Spong, Coor¬ 
dinated Science Laboratory, University of 
Illinois at Urbana-Champaign, 1101 W. 
Springfield Ave., Urbana, 1L 61801, phone 
(217)333-4281. 

ICS 88, 1988 International Computer Sym¬ 
posium: Dec. 20-21, 1988, Taipei, Taiwan. 
Submit paper by July 15, 1988 to Louis R. 
Chow, Tamkang University, Tamsui, Tai¬ 
wan, Republic of China (for authors in the 
Far East); or to Shi-Kuo Chang, Dept, of 
Computer Science, University of Pittsburgh, 
Pittsburgh, PA 15260 (for authors outside 
the Far East). 

Vision 89 (SME): Apr. 25-27, 1989, Chicago. 
Submit abstract by July 15, 1988 to Maria 
Nowakowski, Society of Manufacturing 
Engineers, One SME Dr., PO Box 930, 
Dearborn, MI 48121, phone (313) 271-1500, 
ext. 376. 


Second IEE National Conference on 
Telecommunications: Apr. 2-5, 1989, York, 
England. Submit summary by July 18, 1988 
to IEE Conference Services, Savoy PL, Lon¬ 
don WC2R 0BL, UK, phone 44 (1) 
24-01-871, ext. 222. 


Robots 13 (SME): Spring 1989. Submit 
abstract by July 29, 1988 to Rebecca Alsup, 
Society of Manufacturing Engineers, One 
SME Dr., PO Box 930, Dearborn, MI 48121, 
phone (313) 271-1500, ext. 358. 

IEEE Software: March 1989. Articles 
are sought for a special issue on soft¬ 
ware technology in the Far East. Submit 
manuscript by Aug. 1, 1988 to Carl Chang, 
Guest Editor, EECS Dept., MC 154, Univer¬ 
sity of Illinois, PO Box 4348, Chicago, IL 
60680, phone (312) 996-4860. 


10th Israel Convention on CAD/CAM and 
Robotics: Dec. 27-29, 1988, Tel Aviv. Sub¬ 
mit paper by Aug. 1, 1988 to Secretariat, 
Ortra, Ltd., PO Box 50432, Tel Aviv 61500, 
Israel, phone 972 (3) 66-48-25. 
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j(J)t ASPLOS III, Third International Con¬ 
es' ference on Architectural Support for 
Programming Languages and Operating Sys¬ 
tems (ACM): Apr. 3-6, 1989, Boston. Sub¬ 
mit paper by Aug. 1, 1988 to John Hennessy, 
Center for Integrated Systems, Stanford 
University, Stanford, CA 94305. 


IEEE Infocom 89, Conference on 
Computer Communications: Apr. 
24-27, 1989, Ottawa, Canada. Submit paper 
by Aug. 1,1988 to J.W. Mark, IEEE Info¬ 
com 89, Dept, of Electrical Engineering, 
University of Waterloo, Waterloo, Ontario, 
Canada N2L 3G1, phone (519) 888-4016. 


Second International Workshop of VLSI 
Design (Computer Society of India): Dec. 
15-18, 1988, Bangalore, India. Submit paper 
by Aug. 1, 1988 to Ravi M. Apte, Valid 
Logic Systems, 2820 Orchard Pkwy., San 
Jose, CA 95134, phone (408) 432-9400; or A. 
Prabhakar, Indian Telephone Industries, 
Dooravani Nagar, Bangalore 560 016, India, 
phone 91 (812)56-32-11. 

ETC 89, First European Test Conference 
(SEE): Apr. 12-14, 1989, Paris. Submit 
paper by Aug. 1,1988 to ETC 89, 48 Rue de 
la Procession, 75724 Paris Cedex 15, France. 


Bldg., Gaithersburg, MD 20899, phone (301) 
975-3340; or Robert Fujii, Logicon, 355 W. 
Fifth St., San Pedro, CA 90733, phone (213) 
831-0611. 

IEEE Software: July 1989. Articles are 
v*7 sought for a special edition on parallel¬ 
processing languages. Submit manuscript by 
Sept. 1, 1988 to Shreekant Thakkar, Sequent 
Computer Systems, 15450 SW Roll Pkwy., 
Beaverton, OR 97006. 

17th Computer Science Conference (ACM): 
Feb. 21-23, 1989, Louisville, Ky. Submit 
paper by Sept. 1, 1988 to John D. McGregor, 
Dept, of Computer Studies, Murray State 
University, Murray, KY 42071. 

1989 IEEE Aerospace Applications Confer¬ 
ence: Feb. 5-10, 1989, Breckenridge, Colo. 
Submit summary by Sept. 6, 1988 to Leo 
Mallette, Hughes Aircraft, MS: Bldg. R-10, 
A9026, PO Box 92919, Los Angeles 90009, 
phone (213)334-2909. 

SIGMetrics 89 (ACM, IFIP): May 23-26, 
1989, Berkeley, Calif. Submit paper by Sept. 
10,1988 to Alan Jay Smith, Computer 
Science Division, University of California, 
Berkeley, CA 94720. 


International Workshop on Protocol Test 
Systems (Vancouver Section of the Com¬ 
puter Society): Oct. 12-14, 1988, Vancouver, 
Canada. Submit position statement by Aug. 
8, 1988 to Samuel Chanson or Son Vuong, 
Dept, of Computer Science, University of 
British Columbia, Vancouver, BC, Canada 
V6T 1W5. 

£3^ CompEuro 89, International Confer¬ 
va? ence on VLSI and Computer 
Peripherals: May 8-12, 1989, Hamburg. Sub¬ 
mit paper by Aug. 15, 1988 to Walter E. 
Proebster, IBM Laboratory, PO Box 1380, 
D-7030 Boeblinger, Federal Republic of 
Germany. 


® llth International Conference on Soft¬ 
ware Engineering (ACM): May 15-18, 
1989, Pittsburgh. Submit paper by Sept. 15, 
1988 to Richard Fairley, School of Informa¬ 
tion Technology, George Mason University, 
Fairfax, VA 22030; or Dines Bjorner, Dansk 
Datamatik Center, Lundtoftevej 1 C, 

Lyngby DK-2800, Denmark. 


Transactions on Systems, Man, and Cyber¬ 
netics will publish a special issue on 
unmanned systems and vehicles. Submit 
abstract by Sept. 15,1988 and full paper by 
Nov. 1, 1988 to Arun K. Sood, Dept, of 
Computer Science, George Mason Univer¬ 
sity, 4400 University Dr., Fairfax, VA 
22030-4400, phone (703) 323-2713. 


IEEE Globecom 88: Dec. 1-2, 1988, Holly¬ 
wood, Fla. Submit paper by Aug. 15, 1988 to 
Dennis J. Sassa, Bell Communications 
Research, NVC 2Z-129, 331 Newman 
Springs Rd„ Red Bank, NJ 07701-7020, 
phone (201) 446-6787. 

34th International Instrumentation Sympo¬ 
sium (ISA): Apr. 30-May 4, 1989, Orlando, 
Fla. Submit paper by Aug. 15, 1988 to 
Frederick A. Kern, PO Box 65, Seaford, VA 
23696, phone (804) 865-3269. 

First International Symposium on Artificial 
Intelligence: Oct. 24-28, 1988, Monterrey, 
Mexico. Submit paper by Aug. 31, 1988 to 
Francisco J. Cantu, Instituto Tecnologico de 
Monterrey, ITESM Sue. Correos “J”, Mon¬ 
terrey N.L., Mexico, 64849, phone 52 (83) 
59-59-43. 


IEEE Software: May 1989. Articles are 
va? sought for a special issue on verifica¬ 
tion and validation. Submit manuscript by 
Sept. 1, 1988 to Dolores Wallace, National 
Bureau of Standards, B-266 Technology 


ICCAL 89, Second International Conference 
on Computer-Assisted Learning (Computer 
Learning Research Center): May 9-11, 1989, 
Dallas. Submit extended abstract by Sept. 

15, 1988 Hermann Maurer, IIG, Schiesstatt- 
gasse 4a, A-8010 Graz, Austria, phone 43 
(316)70-255. 


fefjt CHI 89, Conference on Human Fac- 
v§? tors in Computing Systems (ACM, 
HFS): Apr. 30-May 4, 1989, Austin, Texas. 
Submit paper by Sept. 26, 1988 to Clayton 
Lewis, Dept, of Computer Science, Campus 
Box 430, University of Colorado, Boulder, 
CO 80309, phone (303) 492-6657. 


International Symposium on Database Sys¬ 
tems for Advanced Applications (IPSJ, 
KISS): Apr. 10-12, 1989, Seoul, Korea. Sub¬ 
mit paper by Sept. 30, 1988 to Won Kim, 
MCC, 3500 W. Balcones Center Dr., Austin, 
TX 78759-6509, phone (512) 338-3439. 


CAPE 89, Computer Application in Produc¬ 
tion Engineering Conference (IFIP, IPSJ, 
JSPE): Oct. 2-5, 1989, Tokyo. Submit 


extended abstract by Sept. 30, 1988 to Busi¬ 
ness Center for Academic Societies of Japan, 
2-40-14, Hongo, Bunkyo-ku, Tokyo 113, 
Japan, phone 81 (3) 817-5831. 

CMC 89, Colorado Microelectronics Confer¬ 
ence: Mar. 30-31, 1989, Colorado Springs, 
Colo. Submit abstract by Oct. 1, 1988 to 
Technical Chair, CMC 89, Microelectronics 
Research Laboratories, University of 
Colorado, Box 7150, Colorado Springs, CO 
90933-7150. 


Multimedia 89, Second IEEE Comsoc Inter¬ 
national Multimedia Communications 
Workshop: Apr. 20-23, 1989, Ottawa, 
Canada. Submit abstract by Oct. 1, 1988 to 
Nicolas D. Georganas, Multimedia 89, 
Faculty of Engineering, University of 
Ottawa, Ottawa, Ontario, Canada KIN 6N5, 
phone (613) 564-8222. 

1989 IEEE International Conference on 
Robotics and Automation: May 14-19, 1989, 
Scottsdale, Ariz. Submit paper by Oct. 1, 
1988 to John M. Hollerbach, MIT Artificial 
Intelligence Laboratory, 545 Technology 
Square, Cambridge, MA 02139. 

FTCS 19, International Symposium on 
Fault-Tolerant Computing: June 21-23, 

1989, Chicago. Submit abstract by Oct. 14, 
1988 and final manuscript by Nov. 21, 1988 
to S.M. Reddy, FTCS 19, Dept, of Electrical 
and Computer Engineering, University of 
Iowa, Iowa City, Iowa 52242, phone (319) 
335-5196. 


Fifth International Workshop on Software 
Specification and Design: May 19-20, 1989, 
Pittsburgh. Submit extended abstract or 
paper by Oct. 15, 1988 to Colin Potts, MCC, 
9390 Research Blvd., Kaleido II Bldg., Aus¬ 
tin, TX 78759, phone (512) 338-3629. 

SETSS 90, Seventh International Conference 
on Software Engineering for Telecommuni¬ 
cations Switching Systems (IEE): July 3-6, 
1989, Bournemouth, England. Submit syn¬ 
opsis by Oct. 26, 1988 to Conference Ser¬ 
vices, Institution of Electrical Engineering, 
Savoy PI., London WC2R 0BL, UK, phone 
44(1)24-01-871. 


CHDL 89, Ninth International Symposium 
on Computer Hardware Description Lan¬ 
guages and Applications: June 19-21, 1989, 
Washington, DC. Submit paper by Oct. 31, 
1988 to Franz Rammig, University of Pader- 
born, Warburger Str. 100, D4790 Pader- 
born, Federal Republic of Germany. 


® CVPR 89, Conference on Computer 
Vision and Pattern Recognition: June 
4-8, 1989, San Diego, Calif. Submit paper by 
Nov. 16, 1988 to Worthy Martin, Dept, of 
Computer Science, University of Virginia, 
Charlottesville, VA 22903. 


IEEE Software: November 1989. Arri¬ 
val cles are sought for a special edition on 
reverse engineering. Submit manuscript by 
March 1, 1989 to Elliott Chikofsky, Index 
Technology Corp., One Main St., Cam¬ 
bridge, MA 02142, phone (617) 494-8200. 
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BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 


Computer Lib/Dream Machines—Revised and Updated 


Ted Nelson (Tempus Books of 

Microsoft Press, Redmond, Wash., 

1987, 177/153 pp., $18.95) 

The 1987 version of Computer 
Lib/Dream Machines is an update of 
Ted Nelson’s 1974 book by the same 
name. Like the original, this publica¬ 
tion is actually two books in one, bound 
back-to-back. But, like a foreign- 
language translation of a user guide, 
you must turn this book over and 
upside down to start reading the other 
half. 

Unlike the original, this publication 
has only one cover—for Computer 
Lib— which guides the reader to the 
book’s introduction and provides nov¬ 
ice computerists with the background 
necessary to understand where, why, 
and what this book relates to. Old- 
timers and noncomputer-types will miss 
the confusing dual covers of the 1974 
edition. 

I found the introduction particularly 
interesting. Nelson comments that 
many readers of the 1974 edition told 
him that their original copy was stolen 
(Nelson doesn’t use euphemisms). He 
also notes that a disproportionate num¬ 
ber of copies were sold in Canada, and 
that it was difficult to promote the 1974 
edition among either traditional com¬ 
puter or noncomputer markets. 

These comments really struck home 
because I was introduced to Computer 
Lib back in 1974 when I worked for 
IBM Canada as a product planner 
focusing on interactive graphics hard¬ 
ware. I used Nelson’s book to illustrate 
futuristic in-plan graphics features and 
functions that anyone can see today if 
they attend a National Computer 
Graphics Association show. But in 
1974, the only vehicle available to me to 
promote my plans was Nelson’s revolu¬ 
tionary perspective on graphics, which 
was (and still is) in the flip-side of Com¬ 
puter Lib—Dream Machines. 

Computer Lib has been billed as the 
first microcomputer (a term Nelson 


hates) book, but by no means is it only 
for novices—although its orientation 
appears that way. At one level, his 
insightful comments, quotes, and obser¬ 
vations can only be appreciated and val¬ 
ued by liberal-minded computer 
professionals. For example, only those 
of us who have been around for a while 
will really appreciate such gems as: 

“The Dream—you can do anything 
with a computer. The Truth—you’ll 
never have the time.” At an entirely 
different level, the unindexed sections 
of the book can be used as the basis for 
an introductory course in information 
systems. 


The publication 
represents one man’s 
personal hypertext path 
through a vast computer 
technology database. 


Major sections of the book include 
“Guidelines for Writers,” words of 
advice for computer evangelists; “It’s 
All Software,” advice about selecting 
systems and their components; and 
“Magic Languages,” which offers such 
comments as “APL is a jewel, Lisp is a 
bowl of mud. You can’t add to a jewel. 
Adding more mud to a bowl of mud 
gives you a bigger bowl of mud.” 

“Magic Languages” also contains a 
good comprehensive list of program¬ 


ming languages accompanied by superb 
comments on their ancestry and general 
utility. The list even comments in pass¬ 
ing on IPL-V, my own first list-processing 
language (which no one ever seemed to 
have heard of). 

Other sections feature computer 
architecture, operating systems, social 
issues, financial issues, and analytical 
pieces on the major industry movers 
and shakers—from Commodore to 
AT&T, with an extensive review of 
IBM— within a heavily editorialized 
historical perspective. And for a real 
populist perspective on privacy invasion 
issues, the section on information 
(ab)use will give everyone material to 
ponder. And “ponder” is certainly the 
operative verb in Nelson’s depressing 
but perhaps realistic view of issues we 
need to watch as the future unfolds. 

Dream Machines focuses (and I use 
the term generously) on exotic com¬ 
puter applications. Back in 1974 these 
included interactive graphics systems, 
Control Data’s Plato system, and word 
processing. Obviously, yesterday’s 
“dream machines” are today’s fatalities 
or realities. 

From a purely traditional standpoint, 
Nelson’s perspective on dream machines 
is somewhat unconventional. He 
believes that computers are a mecha¬ 
nism that can produce artificial reali¬ 
ties, and that those realities will become 
more real as systems improve. Dream 
machines are the systems that will affect 
that future. Examples of these include 
the Plato system, Ken Knowlton’s 
BEFLIX, and more recently. Nelson’s 
own Hypertext, which is quickly 


If you are interested in reviewing books for Computer, please submit your 
name, address, and a list of areas of interest and expertise to the address above. 
Publishers should submit recent books for review consideration to the same 
address. 
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becoming the 1988 yuppie solution to 
all that ails personal computing. 

Nelson extends this concept to 
include other audio and visual media 
into something he calls “hypermedia,” 
a concept that is far ahead of Apple 
Computer’s relatively simplistic text- 
plus-video media-hopping products. 

Dream Machines includes explana¬ 
tions of such applications as CAD/CAM 
(“perhaps the dumbest term in the com¬ 
puter field”), AI (“what we don’t know 
how to do yet”), information retrieval 
(“one of those terms that laymen throw 
around as it if were a manhole cover”), 
and computer-assisted instruction (no 
comment). 

It is really impossible to reference all 
the material covered in these books. In 
many ways the publication represents 
one man’s personal hypertext path 
through a vast computer technology 
database. Convergent thinkers will miss 
a table of contents and a comprehensive 
subject index, although the book is 
replete with references. But divergent- 
thinking readers will appreciate the 
opportunity to randomly sample some 
very interesting and heretical writing by 
one of the few real straight-shooting 
thinkers in the field of computer-related 
“stuff.” 

Note: The book is also available on¬ 
line on the experimental Xanadu 
Hypertext Network. For details, con¬ 
tact Project Xanadu, 8480 Fredrick- 
sburg, Suite 138, San Antonio, TX 
78229. 

Sorel Reisman 

California State University, Fullerton 


VLSI Engineering 

Thomas E. Dillinger (Prentice Hall, 
Englewood Cliffs, N.J., 1988, 863 
pp., $53.33) 

Very-large-scale integrated systems 
pervade such products of the cybernetic 
marketplace as advanced supercom¬ 
puters, high-speed communications sys¬ 
tems, super industrial controllers, and 
smart logical systems. Further, VLSI 
systems and their sister systems—the 
performance-oriented very-high-speed 
integrated systems—are indispensable 
for solving pressing command, control, 
and communications problems. VLSI 
and VHSI systems are expected to con¬ 
tribute significantly to the detection, 
discrimination, designation, and battle- 
management performance of Strategic 
Defense Initiative-related, efforts of 
ultrahigh concurrency and complexity. 


VLSI Engineering is a comprehensive 
and readable introductory textbook and 
research reference on the engineering 
foundations of integrated systems 
design, modeling, and verification in 
VLSI complementary metal-oxide semi¬ 
conductor technology as well as MOS 
technology. The author’s approach 
evolves naturally from the earlier classic 
work on VLSI technology and physics 
(C. Mead and L. Conway, Introduction 
to VLSI Systems, Addison-Wesley, 

1980) where NMOS technology received 
significant emphasis. The medium used 
to design high-speed and high-complexity 
microelectronic circuitry has shifted in 
recent years from NMOS to CMOS. 

The author even devotes some space to 
the physics of VLSI design (such as 


The book is very well 
written and quite 
comprehensive. 


metastability), but gives no special 
emphasis to structured VLSI or VHSI 
design. 

A novel feature of the textbook is the 
inclusion of yield modeling, test model¬ 
ing, fault modeling, and recommenda¬ 
tions for reducing the adverse effects of 
hardware metastability on computing 
systems of ultrahigh concurrency. On 
the other hand, software metastability 
(such as deadlocks) for VLSI systems is 
not discussed; see, for example, the 
reviewer’s recommendations in 
Abstracts of the American Mathemati¬ 
cal Society, Vol. 3, Jan. 1982, p. 141. 

Each of the 15 chapters includes 
several student exercises, but no solu¬ 
tions. Also, I miss the multicolored 
plates used by Mead and Conway to 
depict processes, structures, layouts, 
and design aids. 

The book covers such basic topics as 
Moore’s exponential growth law for 
integrated circuit capability, VLSI 
design planning, the macro image chip 
design approach, a logic description 
language, logic entry and verification 
tools, a graphics language for physical 
design, physical design tools, pin drop¬ 
ping, and placement algorithms. 

The author goes into the fine struc¬ 
ture of VLSI engineering and con¬ 
densed matter physics, including the 
physics of device concepts, device struc¬ 
tures, device modeling, MOS circuit 
design, fan-in, cell and macro layout, 
special circuit types (such as bootstrap 
circuits and TTL-compatible off-chip 
drivers), array circuit design, test 
methodologies for VLSI, back-end 


design system tools (such as metastabil¬ 
ity), and VLSI process development 
(such as design rules for manufactur¬ 
ing). The book also covers design for 
testability, but without discussing the 
importance of traceability of testing to 
requirements. 

The book is very well written and 
quite comprehensive, although I would 
have liked more hints of where VLSI 
engineering is headed. For example, 
what does the hazy land of ultrahigh- 
speed integrated (UHSI) engineering 
look like (say, at about 20,000 to 50,000 
logic gates per chip)? 

I highly recommend the book for 
advanced undergraduate students and 
professionals in computer science and 
communications engineering who are 
interested in the capabilities and limita¬ 
tions of modern chip-based CMOS 
supersystems. 

Albert A. Mullin 

USA Strategic Defense Command 

Software Product 
Assurance: Techniques for 
Reducing Software Risk 

William L. Bryan and Stanley G. 

Siegel (Elsevier, New York, 1988, 499 

pp., $65) 

This is a very good book. Bryan and 
Siegel have codified much common 
knowledge, common sense, and com¬ 
mon practice into a useful form. 

The text starts with an excellent dis¬ 
cussion of the motivation for product 
assurance and then presents a good 
basic vocabulary. A chapter is devoted 
to the elements of software product 
assurance, and three chapters deal with 
controlling the software as it is devel¬ 
oped and changed throughout its life 
cycle. The final chapter is a great collec¬ 
tion of war stories showing the effec¬ 
tiveness of software product assurance 
in several real projects. 

1 especially like the organization of 
this book. The chapters are ordered 
properly and the inclusion of exercises 
is unusual for a text of this type. Each 
chapter also has an extensive annotated 
bibliography in which the authors note 
the particular applicability of each entry 
to the chapter. Some sources are 
included in multiple chapters, with the 
tie-in to the specific chapter spelled out 
each time. 

The exercises bring the concepts into 
the real world. Too often, books of this 
sort give seemingly good insights into 
product assurance problems, only to be 
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unusable when the actual day-to-day 
problems appear. This book avoids that 
trap by giving the reader a chance to 
work through typical situations using 
the techniques presented. In a class¬ 
room situation, this would make the 
instructor’s task much easier. 

The preface suggests using this text in 
a graduate or advanced undergraduate 
course. Graduate level students might 
find it a bit underwhelming, but I’d be 
glad to use it as a text in, say, a junior- 
level undergraduate course. 

The preface is otherwise quite 
accurate with respect to the book’s 
intended use. I tried each case, putting 
myself into the role of practitioner, 
product manager, and senior manager. 


If you are a more recent 
comer to the world of 
software, buy this text 
today. 


Each time, following the authors’ sug¬ 
gestions on using various parts of the 
book, I found the information appro¬ 
priate. I then read some of the book 
while assuming the viewpoint of various 
practitioners and managers with whom 
I have had product assurance confron¬ 
tations. The text was still compelling 
enough to be hard to ignore. 

There are a few terms and definitions 
I’d like to discuss with the authors, but 
none of them are serious enough that I 
could not recommend the book. I 
would also like to see the chapter bib¬ 
liographies summarized in an index of 
titles. The book contains a complete 
author index, but a title index would 
also be helpful. 

The authors state that the exercises 
have no prescribed solutions; the reader 
is to work them based on his or her own 
situation and understanding of the 
chapter. While I generally agree with 
this approach, an inexperienced practi¬ 
tioner or manager could go astray and 
not know it, coming up with some seri¬ 
ously flawed concepts. Perhaps the 
authors could have provided a few 
“house solutions” to be sure that the 
intended concepts were the ones being 
reinforced. 

The book’s most objectionable fea¬ 
ture (and remember, I really like this 
book) is a plethora of references to the 
Configuration Control Board (CCB), 
which takes a lead role in almost every 
discussion of software control during 
development and maintenance. While I 
agree that control is a basic requirement 
for the delivery of software that is a 


known and satisfactory quantity, many 
control methods do not require a CCB. 
The experienced quality assurance prac¬ 
titioner would see the CCB as a concept 
to be implemented by any appropriate 
means in a given situation. However, 
the apparent requirement could become 
an unnecessary stumbling block to the 
inexperienced practitioner or manager 
(for whom this book is most useful). 

As a reviewer, I am not easily 
pleased. This time I am very pleased. 
This book is a winner for the audiences 
I have mentioned. If you have more 
than five years of experience in software 
and its product assurance, you may not 
find this book necessary. If you are a 
more recent comer to the world of soft¬ 
ware, buy this text today and believe 
what it says. It will help you get your 
software in line and keep it there. 

John W. Horch 
Software quality consultant, 

Madison, Alabama 

Computer Engineering: 
Hardware Design 

M. Morris Mano (Prentice Hall, 
Englewood Cliffs, N.J., 1988, 434 
pp., $48) 

Authors dealing with computer 
design and organization from a hard¬ 
ware point of view have usually taken 
one of two approaches. Some earlier 
books on the subject tended to assume 
that the reader was familiar with digital 
logic circuits and started by examining 
register-transfer-level operations and 
their attendant sequencing. Most mod¬ 
ern texts, however, follow the self- 
contained format in which a short over¬ 
view of required logic-level primitives 
prepares the reader for understanding 
data-path functions and control unit 
design. 

Mano’s book is unusual in that it is 
divided almost equally between low- 
level logic design concepts and high- 
level organizational issues. While this 
approach provides a deeper understand¬ 
ing of hardware operations for those 
who have had little or no formal train¬ 
ing in hardware, such a dual focus 
somewhat weakens the presentation of 
both aspects. At any rate, Mano’s treat¬ 
ment of logic circuits seems to provide a 
level of knowledge somewhere between 
the minimal familiarity needed to 
understand high-level hardware opera¬ 
tions and the detailed knowledge 
required to actually design useful hard¬ 
ware subsystems. 


The book begins with an introductory 
chapter on binary numbers and codes 
and continues with a three-chapter 
overview of digital logic design that 
covers general concepts, combinational 
circuits, and sequential circuits. The 
discussion of logic design concludes 
with Chapters 5 and 6, which discuss 
higher-level hardware components such 
as registers, counters, memories (includ¬ 
ing a three-page discussion of error 
detection and correction), and program¬ 
mable logic devices. 

Chapter 7 covers register transfer and 
computer operations, including micro¬ 
operations, bus transfers, and ALU 
design. Chapter 8 considers micro¬ 
programmed and hardwired control, 
culminating in the design of a six- 
instruction computer with hardwired 
control. Chapter 9 deals with instruc¬ 
tion formats and addressing modes, and 
includes a four-page discussion of inter¬ 
rupts. Chapter 10 presents the design of 
a microprogrammed CPU in considera¬ 
ble detail. The final two chapters exam¬ 
ine input/output and memory 
management. In addition to I/O, Chap¬ 
ter 11 also deals briefly with multiple 
processor systems. 

The problems in each chapter are 
short, straightforward exercises, with 
many one-liners and relatively few 
design-type problems. A solutions man¬ 
ual for the instructor is available from 
the publisher, but I have not examined 
it. Also, about seven references are 
cited at the end of each chapter. 

The emphasis in Chapters 2-6 on the 
1984 ANSI/IEEE standard logic sym¬ 
bols is inconsistent with the depth of 
treatment. Ironically, these symbols— 
and the “dependency notation” also 
emphasized in these chapters —do not 
appear in the second half except in 
Chapter 7 where they only complicate 
otherwise simple diagrams. Also, as in 
one of his previous books (Digital 
Design, Prentice Hall, 1984), Mano 
continually refers to the simplification 
of Boolean functions rather than of 
Boolean or logic expressions. Clearly, 
the representation is simplified, not the 
function. 

The discussion of instruction formats 
and addressing modes in Chapter 9 is 
probably incomprehensible to students 
with no background in assembly lan¬ 
guage programming and trivial for 
those with some low-level programming 
experience on real machines. For exam¬ 
ple, the one-paragraph discussion of 
indirect addressing mode and the single¬ 
page treatment of subroutine call and 
return instructions are woefully inade¬ 
quate for the first group. The same 
observation applies to the author’s 
treatment of stacks and interrupts. 
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Also, floating-point numbers and their 
manipulation should have been 
presented in Chapter 1. 

The CPU design in Chapter 10 is 
needlessly complicated due to awkward 
design choices. For example, the single¬ 
operand register-type instruction is 
treated as a special case of a two-word 
register-memory instruction format 
(where the second word is absent) rather 
than as a special case of the register- 
register format (where one register field 
is unused). However, the most serious 
flaw of this chapter is its adherence to 
outdated notions of a single index regis¬ 
ter, word-oriented instructions (even 
though this means having eight unused 
bits in some formats), and a program 
counter separate from the general regis¬ 
ter file. 

The preface suggests four uses for the 
book: 

(1) a two-term course in basic com¬ 
puter hardware design; 

(2) a first course in digital logic 
design based on Chapters 1-8; 

(3) a course on computer design 
based on Chapters 5-12; or 

(4) a supplement for a course in 
assembly language programming or 
computer organization (Chapters 9-12). 
The second and third suggested uses are 
probably better served by two separate 
texts. Also, excellent texts are available 
that cover the full requirements of the 
fourth course described. 

The first suggested use is possible, 
although it would require an almost 
complete match between the book’s 
coverage and course’s focus. At roughly 
200 pages per course, the instructor 
would not have the flexibility of select¬ 
ing among the topics and examples. On 
the positive side, the students would 
benefit from the continuity of treatment 
and the lower cost of a single text, 
provided the book matches the require¬ 
ments of a two-term course. 

The writing and editing are sloppy, as 
evidenced by the following sentences 
from different parts of the book: 
“Discrete quantities of information 
emerge either from the nature of the 
process or may be purposely quan¬ 
tized from a continuous process.” 

“Computers with multiple processor 
registers employ the Move instruction 
to symbolize the transfer of data 
from one location to another.” 

“Circuits that include flip-flops are 
usually classified by the function they 
perform rather than by the name 
sequential circuit.” 

“Data are discrete elements of infor¬ 
mation that are manipulated to per¬ 


form arithmetic, logic, shift, and 
other data processing tasks.” 

This book is only viable for a two- 
term hardware appreciation course in 
computer science programs that do not 
already have a standard logic design 
course. Instructors in hardware-oriented 
computer engineering programs are 
warned that the book’s title is some¬ 
what misleading. 

Behrooz Parhami 

Carleton University, Ottawa, Canada 


The International Journal 
of Supercomputer 
Applications 

Joanne L. Martin, editor-in-chief 
(MIT Press, Cambridge, Mass., 1987; 
Vol.l, No.l: 120 pp.; No.2: 108 pp.; 
No.3: 107 pp.; and No.4: 117 pp. 
Subscriptions: $50/year for 
individuals, $100.00/year for insti¬ 
tutions) 

The past decade has seen an increased 
emphasis on large-scale computational 
research in a wide variety of disciplines. 
This growth is also marked by an 
increased number of magazines and 
journals relating to all aspects of com¬ 
putational science. The initial publica¬ 
tion of several journals occurred in 
1987, including the International Jour¬ 
nal of Supercomputer Applications, 
published by MIT Press. 

The IJSA provides a forum for 
research, opinions, and ideas on the use 
of supercomputers in solving large-scale 
computational problems without con¬ 
centrating on a particular discipline. In 
this sense, it joins such journals as 
Supercomputer (Amsterdam Universi¬ 
ties Computing Center (SARA), 
Amsterdam) and Parallel Computing 
(North Holland, Amsterdam). 

However, the IJSA is truly an inter¬ 
national journal and not a site journal 
such as Supercomputer. At first glance, 
the IJSA seems to rival Parallel Com¬ 
puting in concept, but on closer exami¬ 
nation it can be argued that the two 
journals are complementary. Parallel 
Computing contains technical papers 
that deal with all aspects of vector and 
parallel computing. The IJSA contains 
technical papers on large-scale com¬ 
puter usage, but also includes articles 
relating to the philosophy and policies 
of large-scale computation. 

The journal’s editorial board com¬ 
prises an impressive international list of 


some 29 scientists and researchers. 
Although dominated by subject experts 
from the US, researchers from Europe 
and the Pacific Rim are also included. 
Papers are initially vetted by the editor- 
in-chief, Joanne L. Martin of the IBM 
T.J. Watson Research Center, and then 
reviewed by a subject expert from the 
editorial board. Papers also undergo an 
additional peer review. 

The technical mission of the IJSA is 
fulfilled through the “Papers” section. 
There generally are between three and 
five full research papers in each issue. 
Individually, these papers are discipline- 
specific, but the authors concentrate for 
the most part on the supercomputer 
aspects of their research. Most papers 
display a real effort to transfer appro¬ 
priate supercomputer experience to 
other disciplines. Because of this, I have 
been able to glean useful information 
even from those papers not associated 
with the types of research presently 
being undertaken at the University of 
Calgary. 


This journal has the 
opportunity to establish 
its own niche in the 
literature. 


Unlike many other technical journals, 
each issue of the IJSA begins with com¬ 
ments from the editor-in-chief or a 
guest editorial written by someone 
closely involved with supercomputers. 
This feature focuses on particularly 
interesting problems or philosophies 
dealing with computational science and 
supercomputers. 

Another unusual feature is that the 
journal is split into a number of other 
special sections, including “Centers of 
Supercomputing, ’ ’ ‘ ‘Correspondence, ’ ’ 
“Perspectives,” and short sections for 
announcements and meetings. These 
special sections, combined with the 
technical papers, make the IJSA a well- 
rounded journal of interest to a wide 
audience. 

In each issue, the “Centers of Super¬ 
computing” section features a paper 
describing the research, format, and 
experiences of a particular supercom¬ 
puting center. Being from a university 
supercomputing center, I appreciated 
the four university sites featured in the 
first volume, but I think some informa¬ 
tion from industrial sites is necessary to 
round out this section. 

To provide a forum for short papers 
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on recent research findings, the IJSA at 
times includes the “Correspondence” 
section. Succinct summaries of research 
discoveries and progress reports on 
ongoing work are published here. These 
are a nice break from the full-length 
papers and are valuable for relatively 
up-to-date notes. 

The “Perspectives” section provides 
a very different flavor and complements 
the technical applications highlighted 
elsewhere. “Perspectives” is just that 
—a philosophical section where ideas 
and concepts are put forward for the 
interest of the readership. This section 
occasionally includes summaries of 
general scientific reports, such as cer¬ 
tain National Science Foundation reports. 

This section and the editorial provide 
entertaining and provocative reading, 
not only for technical readers, but also 
for all those involved with large-scale 
computational mainframes. 

I like the format of the IJSA. The 
technical papers are presented in a two- 
column format, with the main body of 


the text in the inside column. The out¬ 
side column is reserved for figures and 
quotations from the text. The additional 
white space makes the text easier to 
read than is the norm for technical jour¬ 
nals. Type size is standardized, clean, 
and large enough to be easily scanned, 
particularly for equations and code. 

The accompanying figures, however, 
often leave a great deal to be desired. 
Although standards for figure type size 
are recommended by the editor, some 
papers suffer from poorer quality 
figures than expected from a journal of 
otherwise high production quality. It is 
difficult to enforce standard type and 
format for figures in any multiauthored 
publication, but this journal could be 
improved by greater uniformity in the 
diagrams. 

The cover design is simple but effec¬ 
tive: a supercomputer-generated graphic 
is complemented by bold black type for 
the journal title and by the glossy, 
silver-grey background. I also prefer the 
journal’s standard 8 'A X 1 l-inch letter 


size to other, nonstandard sizes. 

The variety of papers and articles 
makes this a journal of interest to a 
wide technical, administrative, and 
managerial audience. For those not 
involved in computational science but 
interested in networking and other 
topics related to this quickly growing 
discipline, there are often items of 
interest in the special sections. 

The IJSA seems to have maintained 
its editorial and production standards 
throughout the first volume. Given the 
rapid rise of computational science 
applications foreseen over the next 
years, this journal has the opportunity 
to establish its own niche in the litera¬ 
ture. If this opportunity can be fulfilled 
and the few minor production problems 
can be addressed, this will definitely be 
a journal to keep handy on the shelf, if 
not on your desk. 


Patricia Comer 
University of Calgary 


NEW LITERATURE 


Three-volume robotics reference. The 

International Encyclopedia of Robotics 
(John Wiley & Sons, 2,000 pp„ $350), 
edited by Richard C. Dorf and with a 
forward by Isaac Asimov, offers arti¬ 
cles from approximately 250 interna¬ 
tional experts on robots and their 
components, characteristics, develop¬ 
ment, design, application, social 
impact, and economic value. Articles 
also examine robot vision, robots in 
Japan and Western Europe, and the 
findings of the Delphi Society, which 
examines the state of robotics in the 
year 2000 and beyond. Contact John 
Wiley & Sons, 605 Third Ave., New 
York 10158; phone (212) 850-6000. 

Communication in the design pro¬ 
cess. Author Patricia J. Guinan 
describes the communication problems 
that occur when system designers try to 
elicit specific requirements from non¬ 
technical users who have only a vague 
idea of what they need in Patterns of 
Excellence for IS Professionals: An 
Analysis of Communication Behavior 
(ICIT Press, 174 pp., $37.50). The book 
includes a five-part training module and 
examines nine US organizations and 
corporations that use good communica¬ 
tion techniques. Contact ICIT Press, 
2000 M St., Washington, DC 20036; 
phone (800) 333-4248. 


The year in technology. The US 

Department of Energy has released 
Technology 87, its annual report on 
technology transfer and new advances 
in general science, energy science and 
technology, and defense-related tech¬ 
nology. The report describes opportuni¬ 
ties to work with the department and 
lists multiprogram laboratories and 
major single-program laboratories. The 
116-page report, stock number 
061-000-00702-4, is available for $8. 
Send prepayment to Dept. 36-N, 
Superintendent of Documents, Wash¬ 
ington, DC 20402-9325. 

1987 computer bibliography. The 

1987 Cumulation of the Computer 
Literature Index includes coverage of 
over 8,200 articles published in nearly 
360 periodicals, and more than 1,100 
books, conference reports, and special 
reports. The literature is organized into 
300 subject classifications and includes 
publisher and publication references. 

The volume is a compilation of the 
quarterly Computer Literature Index. 
The Index is available on a subscription 
basis for $148 a year. The cumulative 
issue consisting of the four quarterly 
issues combined is included in the sub¬ 
scription price. Contact Applied Com¬ 
puter Research, P.O. Box 9280, 
Phoenix, AZ 85068-9280- 


New information processing releases. 
QED Information Sciences has 
announced the publication of several 
new books for information processing 
professionals: 

DB2: The Complete Guide to Imple¬ 
mentation and Use (359 pp., $49.50) by 
Jeff D. Vowell, Jr., discusses the issues 
and topics that management must con¬ 
sider for successful implementation, 
application, and use of DB2. 

The Complete Guide to Software 
Testing ($39.50) by Bill Hetzel presents 
testing techniques, methodologies, and 
management perspectives to aid devel¬ 
opment of testing standards and evalua¬ 
tion of testing effectiveness. 

Logical Data Base Design ($39.95) by 
Robert E. Curtice and Paul E. Jones, 
Jr., organizes logical data base design 
as a set of rules and techniques within a 
single methodological framework. The 
discussion covers strategic principals for 
logical design and factoring of relation¬ 
ships, advanced notation and design 
principles including notational conven¬ 
tions, how to use notation, and fun¬ 
damental rules of logical data base 
design. 

For more information on any of these 
books, contact QED Information 
Sciences, QED Plaza, P.O. Box 181, 
Wellesly, MA 02181-0501; phone (617) 
237-5656. 
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Purpose 

The Computer Society advances the theory and practice of computer 
science and engineering, promotes the exchange of technical 
information among 90,000 members worldwide, and provides a 
wide range of services to members and nonmembers. 

Membership 

Members receive the acclaimed monthly magazine Computer, 
discounts, and opportunities to serve (all activities are led by 
volunteer members). Membership is open to all IEEE members, 
affiliate society members, and others seriously interested in the 
computer field. 

Publications and Activities 

Computer. An authoritative, easy-to-read magazine containing 
tutorial and in-depth articles on topics across the computer field; 
plus news, conferences, calendar, interviews, new products, etc. 

Periodicals. The society publishes six magazines and three 
research transactions. Refer to membership application or request 
information as noted above. 

Conference Proceedings, Tutorial Texts, Standards Documents. 

The Computer Society Press publishes more than 100 titles every 
year. 

Standards Working Groups. Over 100 of these groups produce 
IEEE standards used throughout the industrial world. 

Technical Committees. Over 30 TCs provide newsletters, interac¬ 
tion with peers in specialty areas, and have direct influence on 
standards, conferences, education, etc. 

Conferences/Education. The society holds about 100 conferences 
each-year and sponsors many educational activities, including 
computing sciences accreditation. 

Chapters. Regular and student chapters worldwide provide the 
opportunity to interact with colleagues, hear technical experts, and 
serve the local professional community. 

European Office 

Payments for Computer Society membership and publication 
orders are accepted by cheques in Belgian, British, German, Swiss, 
or U.S. currency, or by American Express, Eurocard, MasterCard, or 
Visa credit cards. 

Ombudsman 

Members experiencing problems—magazine delivery, member¬ 
ship status, unresolved complaints—may write to the ombudsman 
at the Publications Office. 





Innovatioi 



RESEARCH AND DEVELOPMENT: 

Lockheed Artificial Intelligence Center 


Lockheed has established a major center for 
artificial intelligence research, technology 
transfer and training in Menlo Park, California, 
near Stanford University. With a current 
staff of 50, the Center’s growth has created 
openings in both its research and technology 
transfer activities. 

RESEARCH 

At the Center, researchers are provided with 
a fertile research environment, a full comple¬ 
ment of hardware resources and easy access 
to other nearby institutions doing work in Al. 
Our current projects include: 

• EXPLAINABLE SYSTEMS 

• AUTONOMOUS AGENTS 

• IMAGE UNDERSTANDING 

• GENERIC EXPERT SYSTEMS 

• REAL-TIME SYMBOLIC PROCESSING 
ARCHITECTURES 

• INTELLIGENT HUMAN COMPUTER 
INTERFACES 

• KNOWLEDGE ACQUISITION 

• LEARNING SYSTEMS 

• VALIDATION OF KNOWLEDGE-BASED 
SYSTEMS 

We are looking for qualified researchers in 
the following areas: 

GENERIC EXPERT SYSTEMS 

Current efforts focus on developing knowl¬ 
edge representations and problem-solving 
techniques that can be delivered as software 
packages for building knowledge-based 
system applications. 

INTELLIGENT HUMAN COMPUTER 
INTERFACES 

The immediate focus is on designing and 
building interfaces that utilize explicit knowl¬ 
edge of the domain and the user for multi¬ 
modal input/output, understanding user 
intentions, adaptation, response presentation 
and natural language processing. 
KNOWLEDGE ACQUISITION 
We are currently looking at how to capture 
expertise during design.The focus is on 
automatically representing the knowledge 
incorporated in design decisions. 


LEARNING SYSTEMS 

Case-Based Reasonin g 
We are developing a system that solves 
problems by retrieving and adapting cases 
from memory. Current research focuses on 
using Explanation-Based Learning tech¬ 
niques to determine how cases should be 
indexed in memory. 

Inductive Learnin g 

Current efforts focus on developing a system 
to learn complex, structurally defined con¬ 
cepts from examples. 

VALIDATION OF KNOWLEDGE-BASED 
SYSTEMS 

We are building a technology for ensuring 
that the knowledge base in an expert system 
application adheres to user-defined external 
specifications. 

These positions require an advanced degree 
in Computer Science or another Al-related 
field. 

TECHNOLOGY TRANSFER 

A major responsibility of the Center is to 
transfer Al technology to Lockheed Product 
Divisions. Major Lockheed programs such 
as Space Station, Hubble Space Telescope, 
Pilot’s Associate, Milstar and Air/Land Battle 
Management offer exciting domains for the 
application of artificial intelligence 
technology. 

Ideal candidates will have a degree in 
Computer Science or a related field and a 
minimum of two years of Al application 
experience in areas such as maintenance 
and diagnostics, situation assessment, CAD/ 
CAM, CIM, test equipment calibration and 
cost estimation. 

If you would like to explore these unique 
opportunities, we invite you to send your 
resume to L. Moulton, Professional Staffing, 
Dept. 530JALM, Lockheed Missiles & Space 
Company, P.O. Box 3504, Sunnyvale, CA 
94088-3504. We are proud to be an equal 
opportunity, affirmative action employer. 

U.S. citizenship is required. 


Lockheed Missiles & Space Company 


Giving shape to Imagination. 
















